Clase de UML

8/14/2019 Clase de UML

1/173

Introduccin almodelado

Metodologas, UML ypatrones de diseo

Fuente: Ricardo Borillo [email protected]


2/173

ndice Conceptos Lenguajes de modelado: UML Metologas:

Metologas clsicas: RUP, Mtrica, MSF Metologas giles: eXtreme Programming

Patrones de diseo de sofwareArquitecturas dirigidas por modelos (MDA) Herramientas de modelado


3/173


4/173

Componentes bsicos RUP. Tcnicas y su aplicacin a la gestin

de proyectos software orientados a objeto.

XP. Gestin gil de proyectos y grupos dedesarrollo.

UML. Diagramas, elementos notacionales

y semntica de los modelos generados.


5/173

Modelado con UML


6/173

Qu es UML? El UML modela sistema mediante el uso de

objetos que forman parte de l as como, las

relaciones estticas o dinmicas que existenentre ellos.

UML puede ser utilizado por cualquiermetodologa de anlisis y diseo orientada por

objetos para expresar los diseos.


7/173

Qu es UML?

UML es un Lenguaje de Modelado Unificado

basado en una notacin grfica la cual permite:especificar, construir, visualizar y documentarlos objetos de un sistema programado.

Este lenguaje es el resultado de la unificacin

de los mtodos de modelado orientados aobjetos de Booch, Rumbaugh (OMT: ObjectModeling Technique) y Jacobson (OOSE:Object-Oriented Sotfware Engineering).


8/173

UML UML es un lenguaje de modelado que sirve para

visualizar, especificar , construir y documentar

un sistema software.Lenguaje de modelado:

Lenguaje cuyo vocabulario y reglas se centran en la

representacin conceptual y fsica de un sistema

(Booch, Jacobson y Rumbaugh).


9/173

UML para visualizar

Smbolos con semntica bien definida.

UML transciende al lenguaje deprogramacin.

Modelo explcito, que facilita la comunicacin.


10/173

UML para especificar Especificar es equivalente a construir modelos

que cumplan las condiciones de no ambigedad

y completitud. UML cubre la especificacin del anlisis, diseo

e implementacin de un sistema software.


11/173

UML para construir Es posible

hacercorrespondercon loslenguajes de

programacin(Java, C#,B.Datos, etc.).

Modelo

UML

Ingeniera Directa

Ingeniera Inversa

CDIGO


12/173

UML para documentar UML cubre la documentacin de un sistema:

Requisitos

Arquitectura Diseo

Cdigo fuente

Planificacin

Pruebas Prototipos

Versiones


13/173

UML aglutina enfoques OO

UML

Rumbaugh

Jacobson

Meyer

Harel

Wirfs-BrockFusion

Embly

Gamma et. al.

Shlaer-Mellor

Odell

Booch

Pre- and Post-conditions

State Charts

Responsabilities

Operation descriptions,message numbering

Singleton classes

Frameworks, patterns,notes

Object life cycles


14/173

Historia de UML

Nov 97 UML aprobado por el OMG

1998

1999

2000

UML 1.2

UML 1.3

UML 1.4

2001 UML 2.0

Revisiones menores


15/173

Actualizaciones de UML UML 1.3 es una versin madura de UML a la que se

le han aadido una serie de pequeas revisiones, lascuales corrigen o mejoran la especificacin base

(UML 1.2). UML 1.4 incorpora ciertas modificaciones sobre el

estndar en base a los comentarios recogidos de losusuarios finales y de los fabricantes de softwarecompatible con UML.

UML 2.0 promete la puesta a punto del estndar parapoder integrarse con el desarrollo basado encomponentes que demanda el mercado.


16/173

UML 2.0 Arquitectura: refinamiento del ncleo del estndar para

que est en consonancia con el resto de estndares delmercado.

Personalizacin: mejora de los mecanismos deextensibilidad y personalizacin. Componentes: mejor soporte para el desarrollo basado

en componentes (CORBA, EJB, COM+). Mecanismos generales: nuevos mecanimos para el

control de las versiones dentro del modelo, as como elintercambio de los metadatos del mismo con XMI (XMLMetadad Interchange).


17/173

Un proceso de desarrollo de software debe ofrecer unconjunto de modelos que permitan expresar el producto

desde cada una de las perspectivas de inters El cdigo fuente del sistema es el modelo ms detallado

del sistema (y adems es ejecutable). Sin embargo, serequieren otros modelos ...

Cada modelo es completo desde su punto de vista delsistema, sin embargo, existen relaciones de trazabilidadentre los diferentes modelos

Modelos y Diagramas


18/173

Modelos y Diagramas

Modelo: captura una vista de un sistema del mundo

real. Es una abstraccin de dicho sistema,considerando un cierto propsito.

Diagrama: representacin grfica de una coleccin de

elementos de modelado, a menudo dibujada como ungrafo con vrtices conectados por arcos.


19/173

Vista de Diseo

Vista deProcesos

Vista deDespliegue

Vista deImplementacin

Vista de losCasos de Uso

Organizacin de Modelos


20/173

Diagramas de UML

Use CaseDiagramsUse Case

DiagramsDiagramas deCasos de Uso

Scenario

Diagrams

Scenario

DiagramsDiagramas deColaboracin

State

Diagrams

State

DiagramsDiagramas deComponentes

ComponentDiagramsComponent

DiagramsDiagramas deDistribucin

StateDiagrams

StateDiagrams

Diagramas deObjetos

ScenarioDiagrams

ScenarioDiagrams

Diagramas deEstados

Use CaseDiagrams

Use CaseDiagrams

Diagramas deSecuencia

StateDiagrams

State

Diagrams

Diagramas de

Clases

Diagramas de

Actividad

Modelo


21/173

Mecanismos comunes en UML

Especificaciones. Es ms que un lenguaje

grfico (semntica detrs de la notacin).Adornos. Detalles sobre un clase, nivel de

acceso de sus mtodos, notas.Divisiones Comunes: Clase/Objecto o

Interfaz/Implementacin.Extensibilidad. Estereotipos, valores

etiquetados o restricciones.


22/173

Mecanismos comunes en UML


23/173


24/173

Casos de Usos Un diagrama de Casos de Uso muestra la

distintas operaciones que se esperan de una

aplicacin o sistema y cmo se relaciona con suentorno (usuario u otras aplicaciones).

Es una herramienta esencial para la captura derequerimientos y para la planificacin y controlde un proyecto interactivo.


25/173

Casos de Usos Los casos de Uso Se representa en el diagrama

por una elipse que denota un requerimiento

solucionando por el sistema. Cada caso de uso de uso es una operacin

completa desarrollada por los actores y por elsistema en un dilogo.

El conjunto de casos de uso representa latotalidad de operaciones desarrolladas por elsistema.


26/173

Casos de Usos


27/173

Casos de Usos Actor: Es un usuario del sistema, que necesita

o usa alguno de los casos de uso. Un usuario

puede jugar ms de un rol. Un solo actor puedeactuar en muchos casos de uso;recprocamente, un caso de uso puede tenervarios actores. Los actores no necesitan ser

humanos pueden ser sistemas externos quenecesitan alguna informacin del sistema actual.


28/173

Casos de Usos Tambin se puede encontrar tres tipos de

relaciones, como son:

Comunica (comunicates) Entre un actor y uncaso de uso, denota la participacin del actor

en el caso de uso determinado.


29/173

Casos de Usos Usa (uses): Relacin entre dos casos de

uso, denota la inclusin del

comportamiento de un escenario en otro.Se utiliza cuando se repite un caso de usoen dos o ms casos de uso separados.

Frecuentemente no hay actor asociadocon el caso de uso comn.


30/173

Casos de Usos Extiende (extends): Relacin entre dos

casos, denota cuando un caso de uso es

una especializacin de otro. Se usacuando se describe una variacin sobre elnormal comportamiento.


31/173

Casos de Usos Tcnicas comunes de modelado:

Modelado del contexto del sistema (utilidad

similar a los DFD). Modelado de los requisitos de un sistema.

Modelado del proceso de test y estrs del

sistema.


32/173

Diagrama de Clases


33/173

Conceptos bsicos orientacin a

objetos Clase Objeto

Herencia Interfaz Polimorfismo de clases Clases y atributos estticos Clases y atributos finales Clases y mtodos abstractos


34/173

Diagrama de clases Un diagrama de clases o estructura esttica

muestra el conjunto de clases y objeto

importantes que forman parte de un sistema,junto con las relaciones existentes entre clasesy objetos. Muestra de una manera esttica laestructura de informacin del sistema y lavisibilidad que tiene cada una de las clases,

dada por sus relaciones con los dems en elmodelo.


35/173


36/173

Diagrama de clases Clase: representa un conjunto de entidades que

tienen en comn propiedades, operaciones,

relaciones y semntica. Una clase es un constructor que define laestructura y comportamiento de una coleccinde objeto denominados instancia de la clase.

En UML la clase est representada por unrectngulo con tres divisiones internas, son loselementos fundamentales del diagrama.


37/173

Diagrama de clases Atributo: Representa una propiedad de una

entidad. Cada atributo de un objeto tiene unvalor que pertenece a un dominio de valoresdeterminado.

Las sintaxis de una atributo es: Visibilidad : tipo = valor {

propiedades} Donde visibilidad es uno de los siguientes:

+ pblico. # protegido.

- privado.


38/173

Diagrama de clases Operacin: El conjunto de operaciones que

describen el comportamiento de los objetos de

una clase. La sintaxis de una operacin en UMLes:

Visibilidad nombre (lista de parmetros): tipoque retorna { propiedades}


39/173

Diagrama de clases

Nombredela clase

Atributos

Mtodos


40/173

Diagrama de clases

Responsabilidades:Contrato u obligacin de

una clase, asignada en el momento del diseo. Clase Producto:

Registrar el cdigo de la publicacin.

Mantener estructura del producto plantilla.


41/173

Diagrama de clases

Tcnicasde modelado:

Modelado del vocabulario de un sistema apartir de las descripciones funcionales.

Modelado de la distribucin deresponsabilidades en un sistema.

Modelado de cosas que no son software(hardware, personas, etc).

Modelado de tipos primitivos.


42/173

Diagrama de clases Objeto: es una instancia de una clase. Se

caracteriza por tener una identidad nica, unestado definido por un conjunto de valores de

atributos y un comportamiento representado porsus operaciones y mtodos.

Asociacin (rol, multiplicidad, calificador):

representan las relaciones entre instancias declase. Una asociacin es una lnea que une doso ms clases.


43/173

Diagrama de clases

Nombre: Identifica la asociacin entre los

objetos, caracterizndola. Rol: Identificado como un nombre a los finales

de la lnea, describe la semntica de la relacinen el sentido indicado. Cada asociacin tiene

dos roles; cada rol es una direccin en laasociacin. El rol puede estar representado enel nombre de la clase.


44/173

Diagrama de clases

Multiplicidad: Describe la cardinalidad de larelacin, es decir, cuanto objetos de esa clase

pueden participar en la relacin dada. Tipos:


45/173

Diagrama de clases

Dependencia: Es una relacin donde existen

entidades independientes y otras dependientes,lo que implica que cambiar el elementoindependiente puede requerir cambios en losdependientes. Se representa con una lnea

punteada direccional, indicando el sentido de ladependencia.


46/173

Diagrama de clases


47/173

Diagrama de clases Los tipos de asociaciones entre clases

presentes en un diagrama esttico son: Asociacin binaria. Asociacin n-aria.

Composicin.

Generalizacin. Refinamiento.


48/173

Diagrama de clases Asociacin Binaria: Representa una relacin

sencilla entre dos clases, no muy fuerte (es

decir, no se exige dependencia existencial niencapsulamiento). Se indica como una lneaslida que une dos clases.

Asociacin n-aria: Es una asociacin entre tres

o ms clases. Se representa como un diamantedel cual salen lneas de asociacin a las clases.


49/173

Diagrama de clases


50/173

Diagrama de clases Composicin: Es una asociacin fuerte

que implica:

Dependencia existencial. El elementodependiente desaparece al destruirse el quelo contiene y, si es de cardinalidad 1, escreado al mismo tiempo.

Hay una pertenencia fuerte. Se puede decirque el objeto contenido es parte constitutiva yvital del que lo contiene.


51/173


52/173

Diagrama de clases


53/173

Diagrama de clases Agregacin: Relaciona una clase ya

ensamblada con una clase componente.

Es tambin una relacin de composicinmenos fuerte (no se exige dependenciaexistencial) y se denota por un rombo sin

rellenar en un o de los extremos.


54/173

Diagrama de clases


55/173


56/173

Diagrama de clases


57/173

Diagrama de clases Refinamiento: Es una relacin que

representa la especificacin completa de

algo que ya ha sido especificado concierto nivel de detalle. Por ejemplo, unaclase del diseo es un refinamiento de

una clase de anlisis.


58/173

Diagrama de clases


59/173

Diagrama de clases

Tcnicasde modelado:

Modelado de dependencias simples. Modelado de herencia simple.

Modelado de relaciones estructurales(composiciones y agregaciones).

Modelado de comentarios.


60/173

Diagrama de clases


61/173

Diagrama de

Interaccin


62/173

Diagrama de interaccin Estos son modelos que describen como

los grupos de objetos que colaboran en

algunos ambientes. Por lo general, undiagrama de interaccin captura elcomportamiento de un nico caso de uso.

Hay dos tipos de diagramas de

interaccin: diagramasdesecuencia ydiagramasdecolaboracin.


63/173

Diagrama de interaccin Un diagrama de secuencia muestra la

interaccin de un conjunto de objetos de una

aplicacin a travs del tiempo. Esta descripcines importante porque puede dar detalle a loscasos de uso, aclarndolos al nivel de mensajesde los objetos existentes, como tambin

muestra el uso de los mensajes de las clasesdiseadas en el contexto de una operacin.


64/173

Diagrama de interaccin Elementos bsicos del diagrama de

interaccin: Objetos o actores para cada entidad. Enlaces entre los objetos.

Procedimientos a invocar entre los objetos.

Mensajes entre los objetos.


65/173


66/173

Diagrama de interaccin


67/173

Diagrama de interaccin Diagramas de Colaboracin:

Es una forma de representar interaccin entre losobjetos, es decir, las relaciones entre ellos y la

secuencia de los mensajes de las iteraciones queestn indicadas por un nmero A diferencia de losdiagramas de secuencia, pueden mostrar el contextode la operacin (cules objetos son atributos, culestemporales, etc) y ciclos en la ejecucin. Muestra

como varios objetos colaboran en un solo caso deuso.


68/173



69/173

Diagrama de interaccin Tcnicasde modelado:

Modelado dinmico del sistema. Implementacin de un caso de uso en

concreto para cada diagrama.

Modelado del flujo de control por ordenacin

temporal (secuencia). Modelado del flujo de control por organizacin

(colaboracin).


70/173

Diagrama de

Estados


71/173


72/173

Diagrama de estados Estado: Identifica un perodo de tiempo del

objeto (no instantneo) en el cual el objeto esta

esperando alguna operacin, tiene cierto estadocaracterstico o puede recibir cierto tipo deestmulos.


73/173

Diagrama de estados Partes que componen un estado:

Nombre

Acciones de entrada y de salida. Transiciones internas.

Subestados.

Eventos diferidos.


74/173

Diagrama de estados

Eventos: Es una ocurrencia que puede causarla transicin de un estado a otro de un objeto.Esta, puede ser una:

Condicin que toma el de verdadero o falso. Recepcin de una seal de otro objeto en el modelo. Recepcin de un mensaje. Paso de cierto perodo de tiempo, despus de entrar

al estado o de cierta hora y fecha particular.


75/173

Diagrama de estados

Transicin: Es una relacin entre estados deun fuente a un destino.

Partes que componen una transicin: Estado de origen.

Evento de disparo.

Condicin de guarda.

Accin. Estado de destino.


76/173

Diagrama de estados

Otros elementos: Subestados. Secuenciales o no, resultan en una

nueva mquina de estados. Estados de historia.

Estados de historia. Permiten a un conjunto deestados o subestados de un objeto, recordar elestado que estaba activo en su ltima ejecucin. Sino existe historia, se comenzara por el estado inicial.

Subestados concurrentes.


77/173

Diagrama de estados


78/173

Diagrama de estados

Tcnicasde modelado:

Modelado de la vida de un objeto. Este tipode diagramas se asocian directamente auna clase.


79/173

Diagrama de

Actividades


80/173

Diagrama de Actividades

Un diagrama de actividades es un caso especialde un diagrama de estados en el cual casi todoslos estados son estados de accin (identificanque accin se ejecuta al esta en l ) y casi todaslas transiciones son enviadas al terminar laaccin ejecutada en el estado anterior.

Generalmente modelan los pasos de un

algoritmo y puede dar detalle a un caso de uso,un objeto o un mensaje en un objeto.


81/173


82/173


Estado de Accin: representa un estadocon accin interna, con lo menos una

transicin que indica la culminacin de laaccin (por medio de un evento implcito). Permite modular un paso dentro del

algoritmo. Se representan por un rectngulocon bordes redondeados.


83/173


EstadodeActividad:Estado msgeneral que permite su descomposicin

en otro diagrama de actividades interno,de nivel ms bajo. Su representacin, en cuanto a la notacin,

es la misma que el de Accin.


84/173


Casosespeciales:

Estado inicial. Representa el punto de

entrada del diagrama de actividades. Estado final. Su existencia depende de si el

diagrama es cclico.

tem de decisin. Representado con unrombo, permite tomar bifurcacionescondicionales.


85/173


86/173


Transicin:Es la relacin entre dosestados y se encuentran unidos por

flechas; indicando que un objeto que esten el primer estado realizar una accinespecificada y entrar en el segundoestado cuando un evento implcito ocurray unas condiciones especificas seansatisfechas.


87/173


Tiposdetransiciones:

Bifurcaciones condicionales. Permiten tomar

distintos caminos dentro del diagrama enfuncin de una condicin o guarda.

Divisin y unin. Permiten representar elparalelismo en la ejecucin de actividades.


88/173



89/173


Tcnicasde modelado:

Modelado de un flujo de trabajo o Workflow. Usointensivo de estados de actividad, swim lanes ybifurcaciones condicionales.

Modelado de una operacin concreta que resultamuy complicada. Uso intensivo de transiciones

(simples o paralelas) y de estados de accin.


90/173

Diagrama de

Componentes


91/173

Diagrama de componentes

Los diagramas de componentes

describen los elementos fsicosreemplazables del sistema y susrelaciones

Muestran las opciones de realizacinincluyendo cdigo fuente, binario yejecutable


92/173


Los componentes representan todos los tipos

de elementos software que entran en lafabricacin de aplicaciones informticas.Pueden ser simples archivos, libreras,bibliotecas cargadas dinmicamente, etc.

Las relaciones de dependencia se utilizan enlos diagramas de componentes para indicarque un componente utiliza los serviciosofrecidos por otro componente


93/173



94/173


Tcnicasde modelado:

Modelado de ejecutables y bibliotecas. Modelado de tablas, archivos y documentos.

Modelado y diseo de un API.

Modelado del cdigo fuente.

Planificacin de versiones ejecutables para suimplementacin con Nant.


95/173

Diagrama de

Despliegue


96/173


97/173

La vista de despliegue representa la disposicin de lasinstancias de componentes de ejecucin en instancias denodos conectados por enlaces de comunicacin.

Un nodo es un recurso de ejecucin tal como Dispositivos Procesadores Memoria

Los nodos se interconectan mediante soportesbidireccionales que pueden a su vez estereotiparse.

Diagrama de despliegue


98/173


99/173


100/173



101/173


Tcnicasde modelado:

Modelado de procesadores y dispositivos. Modelado de distribucin de componentes.


102/173

RUP: El Proceso

Unificado de Rational


103/173

Proceso Unificado de Rational

Orgenes Modelo original Objectory definido por Ivan

Jacobson (1987) Rational Software compra la empresa de

Objectory (1995)

Surge la primera versin de UML (1997)

Se publica la primera versin del ProcesoUnificado de Rational - RUP (junio 1998)


104/173

Casos de uso Dirigido por casos de uso

Se centra en la funcionalidad que el sistema debe poseer

para satisfacer las necesidades de un usuario (persona,sistema externo, dispositivo) que interactua con l

Casos de uso como el hilo conductor que orienta lasactividades de desarrollo

Casos de Uso

Anlisis

Recopilar,

Clarificar y

Validar los

requerimientos

Diseo

Realizar los

casos de uso

Pruebas

Verificar que se

satisfacen los

casos de uso


105/173


106/173

Modelo que implementa

Iterativo e incremental Descomposicin de un proyecto grande en mini-proyectos Cada mini-proyecto es una iteracin Las iteraciones deben estar controladas Cada iteracin trata un conjunto de casos de uso

Ventajas del enfoque iterativo Deteccin temprana de riesgos Administracin adecuada del cambio Mayor grado de reutilizacin Mayor experiencia para el grupo de desarrollo


107/173

EstructuraDinmica

Ciclo: cada ciclo una nueva versin del producto

Fase: Etapas de un ciclo que finalizan en un HITO

Iteracin: Proceso de ingeniera sobre unafuncionalidad limitada del sistema

Esttica - Flujos de trabajo Artefactos Actividades

Roles


108/173

Estructura

Roles QUIN?

Actividades CMO? Artefactos QU?

Flujo de Trabajo CUNDO?realiza

responsable dediseador diseo de casode uso

diagrama de

secuencia


109/173

Roles

Definicin del comportamiento yresponsabilidades de los participantes

Propietario de una serie de artefactos

Recurso Rol Actividad Artefacto

Diseador Diseo de Objetos DC

Analista Definicin de CU DCUDominio

Diseador Diseo de CU DS

Funcional

Patricia

JuanMnica

Pedro


110/173

Actividades

Unidad de trabajo que puede ejecutar un individuo en unrol especfico

Tiene un propsito claro y se expresa en trminos de

actualizar artefactos La granularidad de la actividad es generalmente de

horas o pocos das Ejemplos de actividades

Planear una iteracin (administrador del proyecto) Encontrar caso de uso y actores (analista del dominio) Revisin del diseo (probador)


111/173

Artefactos

Pieza de informacin producida, modificada yutilizada en un proceso

Productos tangibles del proyecto Utilizados por los roles como entrada para larealizacin de sus actividades Resultado de las actividades realizadas por los

roles

Metamodelo: Clase rol tiene como mtodos lasactividades y como parmetros los artefactos


112/173

Flujos de trabajo

Forma de describir significativamente la

secuenciencias de actividades que producenresultados y las interacciones entre cargos

En trminos de UML se puede utilizar:diagrama de actividades, de secuencia, decolaboracin

En RUP hay nueve tipos de flujos de trabajo De ingeniera

Negocio, Requerimiento, Anlisis, Diseo, Pruebas,Liberacin

De soporte


113/173

Dimensin dinmica

Concepcin Elaboracin Construccin Transicin

ciclofase

Iter. 1 Iter. 2 Iter. 3 Iter. 4 Iter. 5 Iter. 6

hito 1 hito 2 hito 3 hito 4

Hito: punto en el tiempo en donde se evaluan objetivos

logrados y se pueden tomardecisiones crticas


114/173

Desarrollo iterativo

Ciclo de

desarrollo 1

Ciclo de

desarrollo 2

Ciclo de

desarrollo n

Perfeccionar

el plan

Sincronizar

Artefactos

Anlisis Diseo Construccin Pruebas

Construccin


115/173

Fase de concepcin

Objetivo: definir la razn de ser y el alcance delproyecto. Estudio de oportunidad. Visin = QU + PARA QU + CUNTO

Actividades Especificacin de los criterios de xito del proyecto Definicin de los requerimientos Estimacin de los recursos necesarios Cronograma inicial de fases

Artefactos Documento de definicin del proyecto


116/173

Fase de elaboracin

Objetivo: establecer un plan de proyecto y unaarquitectura correcta del sistema

Actividades Anlisis del dominio del problema Definicin de la arquitectura bsica Anlisis de riesgos Planificacin del proyecto

Artefactos Modelo del dominio Modelo de procesos Modelo funcional de alto nivel Arquitectura bsica


117/173


118/173

XP: eXtreme

Programming


119/173

eXtreme Programming Es una metodologa gil

Diseada para entornos dinmicos

Pensada para equipos pequeos (hasta10 programadores)

Orientada fuertemente hacia lacodificacin

nfasis en la comunicacin informal,verbal


120/173

Valores que fomenta XP Comunicacin

Simplicidad

Retroalimentacin

Coraje


121/173

Roles

Programador(Programmer) Responsable de decisiones

tcnicas Responsable de construir el

sistema

Sin distincin entre analistas,diseadores o codificadores

En XP, los programadoresdisean, programan y realizanlas pruebas

Jefe de Proyecto(Manager)

Organiza y gua lasreuniones

Asegura condicionesadecuadas para elproyecto

Cliente (Customer) Es parte del equipo Determina qu construir

y cundo Establece las pruebas

funcionales


122/173

Roles Entrenador(Coach)

Responsable del proceso

Tiende a estar en unsegundo plano a medidaque el equipo madura

Encargado de

Pruebas (T

ester) Ayuda al cliente con

las pruebasfuncionales

Se asegura de quelas pruebasfuncionales sesuperan

Rastreador(Tracker)


123/173

Captura de requisitos HistoriasdelUsuario(User-Stories)

Establecen los requisitos del cliente

Trozos de funcionalidad que aportan valor

Se les asignan tareas de programacin conun n de horas de desarrollo

Las establece el cliente Son la base para las pruebas funcionales


124/173

Planificacin Planificacin por entregas (releases)

Se priorizan aquellas user-stories que el clienteselecciona porque son ms importantes para elnegocio

Entregas:

Son lo ms pequeas posibles Se dividen en iteraciones (iteracin = 2 o 3

semanas)

Estn compuestas por historias

A cada ro ramador se le asi na una tarea de


125/173

Programacin

La programacin de tareas se realiza porparejas

La pareja disea, prueba, implementa eintegra el cdigo de la tarea

Cdigo dirigido por las pruebas Cdigo modular, intentando refactorizar

siempre que se pueda


126/173


127/173

Prcticas El juego de la

planificacin

Entregas pequeas

Metfora

Diseo simple

Pruebas Refactoring

Programacin enparejas

Propiedad colectiva

Integracin contnua

Semana de 40 horas

Cliente in situ

Estndares deprogramacin


128/173

El juego de la planificacin

Decisiones de negocio (cliente): Alcance Cundo debe estar listo el producto para

que sea valioso en produccin? Prioridad Prioriza la incorporacin de las user-

stories

Composicin deentregas Qu se necesita para

que el negocio sea mejor antes de tener el sw? Fechasdeentrega Fechas cuando el software

funcionando causara una gran diferencia


129/173

El juego de la planificacin

Decisiones tcnicas (programadores y otros): Estimaciones Cunto tiempo tardar en

implementarse una user-story? Consecuencias Tener en cuenta las

consecuencias tcnicas de determinadas decisionesde negocio

Proceso Organizacin del proceso y el equipo Planificacin detallada Dentro de una entrega,

qu

user-stories se realizan primero. Intentar trasladar los

segmentos de desarrollo ms arriesgados al


130/173

Cada entrega es lo ms corta posible: Contenga requisitos ms valiosos del sistema

(bsicos)

Reducen el riesgo mayor retroalimentacin desde elcliente, y ms frecuente

Minimizar el n de user-stories que componenuna entrega No realizar user-stories a medias

Entregas pequeas


131/173

Se diseala cosa ms simple que puedafuncionar

Uso de tarjetas CRC

Diseo de software correcto, es aquel que: Supera todas las pruebas

No tiene lgica duplicada Pone de manifiesto las intenciones importantes de

los programadores

Tiene el mnimo nmero de clases y mtodos

Diseo simple


132/173

Las pruebas unitarias se escriben ANTES que elcdigo

Pruebas automatizadas Permiten el desarrollo de proyectos de forma

rpida y segura Pruebas unitarias programadores

Pruebas funcionales

cliente Resultado Un programa cada vez ms seguro

Pruebas


133/173

NUnit

Framework para pruebas unitarias

Escritura de pruebas

Ejecucin de pruebas Hacer un Assert de los resultados

Mostrar los fallos o xitos

Mantener un cdigo que pase los tests

http://nunit.org/


134/173

Ejemplo de un test en NUnit


135/173

it j i d l t t


136/173

xito en ejecucin de los tests


137/173

Refactorizacin = Mejora del cdigo

Intentar eliminar complejidad

Cdigo duplicado Refactorizacin

Se plantea su aplicacin despus deimplementar cada user-story

Refactoring


138/173

C# Refactoring

Herramientas integradas con Visual Studio

Simplifican la refactorizacin del cdigo Mtricas para el anlisis del cdigo

http://www.xtreme-simplicity.net/


139/173

Integracin con Visual Studio


140/173

Mtricas de anlisis del cdigo


141/173


142/173

Toda el cdigo se escribe en parejas

Se produce cdigo de mayor calidad

Extiende el conocimiento

Se realiza el trabajo de 1 persona en casi la

mitad del tiempo y mejor (cuestionable)

Programacin en parejas


143/173

Cualquiera puede modificar el cdigo encualquier momento Se evitan cuellos de

botella en la codificacin

Todos asume las responsabilidades sobre elconjunto del sistema

Todos conocen algo sobre todas las partes yconocen muy bien aqullas en las que trabajan

Propiedad colectiva


144/173

El cdigo se integra y se prueba despus depocas horas

Existe una ordenador dedicado para laintegracin

Cada pareja integra su cdigo en dichoordenador

Integracin contnua


145/173

Cliente real = Aquel que usar el sistemacuando est en produccin

El cliente real debe estar con el equipo detrabajo: Responder preguntas

Resolver disputas Establecer prioridades Discutir mejoras

Cliente in situ


146/173


147/173

Patrones de diseo

software

Definicin


148/173

Definicin

Cada patrn describe un problema que

ocurre una y otra vez en nuestro ambiente,y luego describe el ncleo de la solucin aese problema, de tal manera que puedesusar esa solucin un milln de veces ms,

sin hacer jams la misma cosa dos veces(ChristopherAlexander)

Son soluciones reutilizables a problemasrecurrentes que encontramos durante el

Ventajas que ofrece el uso de


149/173


patrones Disear cdigo orientado a objetos es

costoso, y disear cdigo orientado objetos

reutilizable an lo es ms Los patrones permiten a losprogramadores reconocer un problema einmediatamente determinar la solucin sintener que pararse a analizar el problema

primero Permiten trabajar a un nivel de abstraccin

mayor Aumentan la productividad, la reutilizacin

del cdigo y su consistencia



150/173

j q

patrones Capturan la experiencia en diseo. Los

patrones se crean a partir de ejemplos

prcticos de diseo Utilizar patrones de diseo es reutilizar la

experiencia adquirida diseando

Estudiar los patrones existentes es unamanera de aprender cmo los expertosdisean sistemas

Los patrones definen un conjunto de trminos

Componentes que constituyen un


151/173

Componentes que constituyen un

patrn Nombre

Resumen o esencia de la solucin

Contexto al que se aplica

Razones para utlizar o no el patrn

Consideraciones de implementacin

Consecuencias e implicaciones de su uso Ejemplo de uso (Test Case)

Patrones relacionados


152/173


153/173

Clasificacin de los patrones Fundamentales De creacin De particin Estructurales De comportamiento De concurrencia

Fundamentales


154/173

Fundamentales

Son los patrones ms bsicos yfundamentales:

Muchos del resto de patrones utiliza al menosuno de ellos

Son tan bsicos que muchas veces no semencionan dndolos por supuestos


155/173

Delegate Interface Abstract superclass Interface + abstract class Immutable

Proxy

Fundamentales


156/173

Provee de una gua de cmo crear objetoscuando su creacin precisa de la toma dedecisiones: Las decisiones normalmente involucran la

determinacin de forma dinmica de qu claseinstanciar o a qu objeto delegar la responsabilidad

Estos patrones nos ayudan a estructurar y

encapsular las decisiones

De creacin

De creacin


157/173

De creacin

Factory Builder Prototype Singleton Object pool

De particin


158/173

De particin

Siguen el paradigma de divide yvencers

Nos proporcionan la gua de cmoparticionar las clases e interfaces para llegara un buen diseo

De particin


159/173

De particin

Filter

Composite

Read-only interface

Estructurales


160/173

Estructurales

Describen las formas ms comunes enlas que diferentes tipos de objetos pueden

organizarse para trabajar conjuntamente

Estructurales


161/173

Estructurales

Adapter Iterator Bridge Faade Flyweight

Dynamic linkage Virtual proxy Decorator Cache management

D i


162/173

De comportamiento

Patrones utilizados para organizar,gestionar y combinar comportamiento

D i


163/173

De comportamiento

Chain of responsibility

Command

Little language Mediator

Snapshot

Observer

State Null object

Strategy

Template method

Visitor

D i


164/173

De concurrencia

Patrones para la coordinacin deoperaciones concurrentes y que permiten

solucionar dos problemas principalmente: Recursos compartidos

Secuenciacin de operaciones

D i


165/173

De concurrencia

Single threaded execution

Lock object

Guarded suspension Balking

Scheduler

Read/Write lock

Producer-consumer

Two-phase termination

Double buffering

Asynchronous processing

Future


166/173

Arquitecturas dirigidas

por modelos (MDA)


167/173

PIM, PSM y transformaciones enMDA


168/173

MDA

Reglas de transformacin

Modelo especfico(PSM)

Modelo independiente de la plataforma(PIM)

Modelo especfico(PSM)


169/173


170/173

Herramientas de

apoyo al modelado

Herramientas de apoyo ald l d


171/173

Herramientas comerciales generales: Borland Together IBM Rational Suite

Herramientas libres o con versiones bsicasgratuitas: Argo UML Poseidon

Umbrello Eclipse UML2 Eclipse Omondo

Integracin con los IDEs existentes

modelado

Ayuda a la generacin de


172/173

Herramientas con soporte de ingenierainversa

Herramientas de generacin en un solo sentido Herramientas de soporte MDA:

Together AndroMDA

cdigo


173/173

Clase de UML

Documents

Transcript of Clase de UML