Se u1 by Juan Carlos Olivares Rojas

IngenierĂa de Software II 0840 M.C. Juan Carlos Olivares Rojas

Septiembre 2009

Agenda

1. Conceptos del Diseño Orientado a Objetos 2. Diseño e Implementación de Bases de Datos Orientados a Objetos 3. Diseño de Sistemas utilizando UML 4. Diseño de la Interfaz de Usuario

Calidad de Software

• La calidad hace referencia intrínseca a eficacia y eficiencia. • ¿Qué tiene más calidad un “Vochito” o un BMV? • Los dos tienen igual calidad si cumplen con los requerimientos (checklist).

Calidad de Software

• En general la Ing. Sw tiene los objetivos de que el software sea correcto, utilizable y costoefectivo. • Sinónimos de calidad es que esté libre de errores. Muchas de las metodologías de software actuales se basan en esta premisa.

Calidad de Software

• ¿Por qué es difícil lograr la calidad del software? • El software es un producto intangible el cual se logra a través de un proceso creativo ya que programar es un arte, el cual no puede ser sistematizado del todo.

Calidad de Software

Calidad de Software • ¿Por qué es importante el Desarrollo de Proyectos de forma Metodológica? El software es cada vez más complejo y costosos que se compara con construir un edificio. • En 1968 se da un hito importante al ocurrir la “crisis del software” y definirse la Ingeniería de Software como tal.

Construcción de una casa para “wendo”

Puede hacerlo una sola persona Requiere: Modelado mínimo Proceso simple Herramientas simples

Construcci贸n de una casa

Construida eficientemente y en un tiempo razonable por un equipo Requiere: Modelado Proceso bien definido Herramientas m谩s sofisticadas

Construcción de un rascacielos No cualquier persona o grupo de persona lo realiza. Imposible sin técnicas de Ingeniería

Fábricas de Software

• Tratan de automatizar los procesos de desarrollo de software tal cual lo realizan las líneas de producción de los sistemas industriales. • No es nuevo pero actualmente está teniendo mucho éxito. Requiere de mucho esfuerzo. Es un modelo organizacional.

Verdadero Ciclo de Vida del Desarrollo de un Proyecto

Primera fase

Segunda fase

Tercera fase

Cuarta fase

Metodologías de Desarrollo de Software

• Las metodologías de software son un conjunto de “mejores prácticas” que si no se llevan a la práctica no sirven de nada. • El factor humano es el recurso más importante de cualquier proyecto de software.

Metodologías de Desarrollo de Software

• Por ejemplo, la Ley de Brooks: Si se aumenta un programador más se retrasa el proyecto mientras se explica que hay que hacer. • El proceso de desarrollo de software implica cuatro etapas:

Ley de Brooks

Metodologías de Desarrollo de Software

– Especificación – Desarrollo – Evaluación – Evolución

• El desarrollo de software se basa en modelos, siendo los más representativos:

• • • •

Metodologías de Desarrollo de Software

Cascada (clásico) Construcción de prototipos Espiral RAD (Desarrollo rápido de aplicaciones)

• Cada uno de estos modelos tiene sus respectivas fases que pueden ser muy similares entre sí.

Modelos de Ciclo de Vida

Cascada

Modelo Ciclo de Vida en Cascada Actual

• Comunicación:

– Inicio del Proyecto – Recopilación de Requerimientos

• Planeación:

– Estimación – Itinerario – Seguimiento

Modelo de Ciclo de Vida en Cascada Actual

• Modelado

– Análisis – Diseño

• Construcción – Código – Prueba

Modelo de Ciclo de Vida en Cascada Actual

• Despliegue:

– Entrega – Soporte – Retroalimentación

• En el modelo iterativo se repiten algunas fases al igual que en espiral.

Modelo de Ciclo de Vida en Cascada Actual

Flujos de Trabajo de las Etapas Inicio

Despliegue Implementación Diseño Análisis 0

100

Flujos de Trabajo de las Etapas Elaboraci贸n

Despliegue Implementaci贸n Dise帽o An谩lisis 0

100

Flujos de Trabajo de las Etapas Construcci贸n

Despliegue Implementaci贸n Dise帽o An谩lisis 0

100

Flujos de Trabajo de las Etapas Transici贸n

Despliegue

Implementaci贸n

Dise帽o

An谩lisis 0

100

Modelo Iterativos

Modelo en Espiral

MetodologĂas Ă giles

¿Qué es una Metodología Ágil? • Las Metodologías Ágiles (MAs) valoran:

– Al individuo y las interacciones en el equipo de desarrollo más que a las actividades y las herramientas – Desarrollar software que funciona más que conseguir una buena documentación ⇒ Minimalismo respecto del modelado y la documentación del sistema – La colaboración con el cliente más que la negociación de un contrato – Responder a los cambios más estrictamente una planificación

que

seguir

Costo de los Cambios en SW Tradicional Costo del cambio

Suposici贸n MAs tiempo

Comparación Ágil v/s Tradicional Metodología Ágil

Metodología Tradicional

Pocos Artefactos. El modelado es prescindible, modelos desechables.

Más Artefactos. El modelado es esencial, mantenimiento de modelos

Pocos Roles, más genéricos y flexibles

Más Roles, más específicos

No existe un contrato tradicional, debe ser bastante flexible

Existe un contrato prefijado

Cliente es parte del equipo de desarrollo (además in-situ)

El cliente interactúa con el equipo de desarrollo mediante reuniones

Orientada a proyectos pequeños. Corta duración (o entregas frecuentes), equipos pequeños (< 10 integrantes) y trabajando en el mismo sitio

Aplicables a proyectos de cualquier tamaño, pero suelen ser especialmente efectivas/usadas en proyectos grandes y con equipos posiblemente dispersos

La arquitectura se va definiendo y mejorando a lo largo del proyecto

Se promueve que la arquitectura se defina tempranamente en el proyecto

Énfasis en los aspectos humanos: el individuo y el trabajo en equipo

Énfasis en la definición del proceso: roles, actividades y artefactos

Se esperan cambios durante el proyecto

Se espera que no ocurran cambios de gran impacto durante el proyecto

Principales MAs •

Crystal Methodologies, Alistarir Cockburn, www.crystalmethodologies.org

•

SCRUM, Ken Schwaber & Jeff Sutherland, www.controlchaos.com

•

DSDM (Dynamic Systems Development Method), www.dsdm.org

•

Lean Programming, Mary Poppendieck, www.poppendieck.com

•

FDD (Feature-Driven Development), Peter Coad & Jeff De Luca, www.nebulon.com/fdd, www.coad.com/peter/#fdd

•

Extreme Programming, Kent Beck www.extremeprogramming.org, www.xprogramming.com

Programaci贸n Extrema eXtreme Programming (XP)

Historia de XP • Creada por Kent Beck a raíz de su experiencia en el proyecto C3 en Chrysler

 Kent fue contratado para dirigir el proyecto  Durante el proceso nació una nueva metodología: eXtreme Programming (XP)  C3 concluyó exitosamente en 1997

Valores que fomenta XP • Comunicación • Simplicidad • Retroalimentación • Coraje

Roles XP Programador

– Responsable de decisiones técnicas – Responsable de construir el sistema – Sin distinción entre analistas, diseñadores o programadores – En XP, los programadores diseñan, programan y realizan las pruebas

Jefe de Proyecto (Manager)

– Organiza y guía las reuniones – Asegura condiciones adecuadas para el proyecto

Cliente (Customer)

Es parte del equipo Determina qué construir y cuándo Establece las pruebas de aceptación

... Roles XP Encargado de Pruebas (Tester)

– Ayuda al cliente con las pruebas de aceptación – Se asegura de que las pruebas aceptación se superan

Rastreador (Tracker)

“Metric Man” Observa sin molestar Mantiene datos históricos

Entrenador (Coach)

– Responsable del proceso – Tiende a estar en un segundo plano a medida que el equipo madura

Artefactos esenciales en XP • Historias del Usuario • Tareas de Ingeniería • Pruebas de Aceptación • Pruebas Unitarias y de Integración • Plan de la Entrega • Código

Historia de Usuario Historia de Usuario Número: 1 Nombre: Enviar artículo Usuario: Autor Modificación de Historia Número: Iteración Asignada: 2 Prioridad en Negocio: Alta Puntos Estimados: (Alta / Media / Baja) Riesgo en Desarrollo: Puntos Reales: (Alto / Medio / Bajo) Descripción: Se introducen los datos del artículo (título, fichero adjunto, resumen, tópicos) y de los autores (nombre, e-mail, afiliación). Uno de los autores debe indicarse como autor de contacto. El sistema confirma la correcta recepción del artículo enviando un e-mail al autor de contacto con un userid y password para que el autor pueda posteriormente acceder al artículo. Observaciones:

Spike para Historia de Usuario

Prueba de Aceptación

Caso de Prueba

Número Caso de Prueba: Nombre Caso de Prueba: Descripción:

Condiciones de ejecución:

Entradas:

Resultado esperado: Evaluación:

Número Historia de Usuario:

Escenarios en XP : Exploraci贸n ?

Historias de Usuario Prioridad

Riesgo Esfuerzo (puntos)

Definir Historias de Usuario

Elaborar Spikes

Spikes (Bosquejos)

Estimar Esfuerzo y Riesgo

Escenarios en XP: Planificación de la Entrega

Velocidad de Proyecto (VP) puntos/semana

Historias de Usuario Primera Iteración

Segunda Iteración

N-ésima Iteración

…

2a3 semanas Entrega <= 3 meses

Última Iteración

Historias fuera de la entrega

Escenarios en XP : Comenzar Iteraci贸n

Historias de la Iteraci贸n

Definir y ordenar Tareas de Ingenier铆a

Tareas de la iteraci贸n

Escenarios en XP : Programación

Historias de la Iteración Tareas de Historias de la iteración Programación en Parejas

Versión del Producto

Diseño Refactoring Programación Pruebas Unitarias Integración Pruebas de Integración Pruebas de Aceptación

Pruebas de Aceptación de Historias de la iteración

Escenarios en XP : Pruebas de Aceptaci贸n

Definir Pruebas de Aceptaci贸n

Pruebas de Aceptaci贸n

Corregir errores Definir nuevas Historias Aplicar Pruebas de Aceptaci贸n

Entorno y clima de trabajo Espacio de trabajo XP • Espacio abierto • Mesas centrales • Cubículos en el espacio exterior

Espacio de trabajo del proyecto C3 de DaimlerChrysler

… Entorno y clima de trabajo Reunión diaria XP • Reunión diaria: “Stand-up Meeting”

– Todo el equipo • Problemas • Soluciones

– De pie en un círculo

• Evitar discusiones largas • Sin conversaciones separadas

¿Cuándo utilizar una Metodología Ágil? • ¿Tienes ya un proceso? No

o existe pero no reacciona bien a los cambios o existe pero el equipo no está contento con él

⇒ Una Metodología Ágil puede ser una buena forma de empezar • No involucra gran inversión • A los programadores les (suele) gustar • A los clientes les ofrece mayor visibilidad y menor riesgo en el proyecto

Ejemplo de Metodologías • Problema: El profesor se encuentra actualmente ante una necesidad de extrema importancia. Necesita realizar una corbata para ir a una junta en donde se encontrarán altos empresarios del sector informático, el detalle es que no sabe a ser un nudo de corbata • ¿Cómo podría resolver el problema?

Ejemplo de Metodologías

• La solución más fácil es realizar outsorcing (que lo hagan otros). • Sino se puede, se deberá realizar en base a tres formas básicas de solución de problemas: • Conocimiento • Experiencia • Sentido Común

Ejemplos de Metodologías • La forma más fácil es a través de una metodología para realizar nudos de corbatas como la planteada en http://www.nudo-decorbata.com/ • Lo primero que se tiene que saber es si debe ser un tipo especial de corbata o no. Los tipos pueden ir desde nudo de corbata simple, doble, windsor, medio windsor, nudo pequeño.

Simple

Doble

Windsor

Medio Windsor

Nudo peque単o.

Nudo Cruzado

Requerimientos

• Un requisito no es otra cosa que una condición o capacidad de un usuario o sistema para satisfacer un objetivo o resolver un problema. • Los requerimientos pueden ser funcionales (explícitos) o no funcionales (implícitos).

Requerimientos • Las características que deben perseguir los requerimientos son: necesario, conciso, completo, consistente, no ambiguo, verificable. • Los problemas que presenta la Ingeniería de Requerimientos son muchos:

Requerimientos

• Los requerimientos no son obvios y provienen de muchas fuentes. • Son difíciles de expresar en palabras. • Un requerimiento puede transcurso del proyecto.

cambiar

Requerimientos

â&#x20AC;˘ Lo que se pretende con una buena IngenierĂa de Requerimientos es reducir costos y retrasos del proyecto, mejorar la calidad del software, evitar el rechazo de los usuarios finales entre otras cuestiones.

Requerimientos

• Es muy importante definir los límites y alcances del sistema. • El éxito de la obtención de requerimientos consiste en ponernos en los zapatos de nuestros clientes y no desarrollando a nuestros gustos.

Diferentes Vistas

Requerimientos â&#x20AC;˘ Se deben evaluar y negociar cada uno de los requerimientos con el fin de priorizar cada uno de los requerimientos. â&#x20AC;˘ Se deben documentar cada uno de los requerimientos obtenidos asĂ como el control del cambio.

Requerimientos

• Para obtener requerimientos se siguen muchas técnicas. Las más populares son las entrevistas y cuestionarios. • Tips para Diseñar Cuestionarios. • Es necesario realizar un muestreo de los datos para encontrar necesidades.

Requerimientos • Se deberán poner escalas (preguntas cerradas) para cuantificar lo que se pretende. • Actividad: diseñar un cuestionario sobre el proyecto y aplicarlo a por los menos a 20 personas. Se sugiere utilizar sistemas en líneas para realizar los cuestionarios. (Diseño:20%, Aplicación:80%)

FODA

• Se pueden utilizar técnicas como la Lluvia de Ideas o análisis FODA, el cual consiste en hacer una relación entre elementos: • • • •

Fortaleza: Factor interno positivo. Oportunidades: Factor externo positivo. Debilidades: Factor interno negativo. Amenazas: Factor externo negativo.

Requerimientos

• Actividad: Realizar un análisis FODA del proyecto. Cada integrante del equipo se encarga de un área y se junta (100%) • Otras técnicas de obtención de requerimientos son: • Matriz de requisitos • Metodología FURPS+

Metodología FURPS+

• Funcional (Functional): capacidades y seguridad.

características,

• Facilidad de Uso (Usability): humanos, ayuda, documentación.

factores

• Fiabilidad (Reliability): frecuencia de fallos, capacidad de recuperación.

Metodología FURPS+

• Rendimiento (Performance): respuesta, productividad, disponibilidad, uso de los recursos

tiempos de precisión,

• Soporte (Supportability): adaptabilidad, facilidad de mantenimiento, internacionalización, configurabilidad.

Metodología FURPS+ • +: • Implementación: limitación de recursos, lenguajes y herramientas, hardware • Interfaz: restricciones impuestas para la interacción humana • Operaciones: gestión del sistema • Empaquetamiento • Legales: licencias, auditorias, etc.

Métodología FURPS Req

Consultas a Deberán Pocos través de realizarse a movimient un celular través de os del SMS/MMS, teclado la respuesta será en MMS Sistema Web de Captura Indicadore s …

Optimizad Soporte en o para Plataforma desplegar s J2ME informació n importante

Seguridad por autenticaci ón y huella digital

Optimizad o para navegador Opera ….

+ Ejecutarse con Equipos Nokia serie 60

Factores Críticos de Éxito

• La metodología de Factores Críticos de Éxito sirven para determinar aquellas áreas o cosas que son críticas para la empresa. • El FCE nos ayuda a enfocar nuestros esfuerzos y en determinar como se debe monitorear cada una de nuestras alternativas.

FCE • No son medidas estándar para toda la industria, ni para todos los negocios. Son específicos para una situación particular en un momento dado. • Pueden ser medidos cualitativamente

cuantitativa

• Existen factores:

FCE

– Internos – Externos – De seguimiento de operaciones – De seguimiento de planes

FCE • Principales fuentes (según Rockart):

– La industria – La estrategia competitiva o posición en la industria – Factores del medio ambiente – Factores temporales – Posición administrativa

FCE • Algunos FCE Automotriz: • • • •

Industria

Economía en el combustible Imagen Organización eficiente de agencias Control de costos de manufactura, etc.

FCE

• Se deben considerar los siguientes elementos: • Información crítica: información necesaria para dar seguimiento a los FCE (extraída de otros SI, comprada, etc.)

FCE • Supuestos críticos: Los objetivos y FCE están basados en supuestos. Deben ser validados constantemente. Ej. Actividades de la competencia, inflación, etc. • Decisiones críticas: Determinar cuáles son las decisiones críticas que se deben hacer. Ej. ¿dar de baja un producto?, ¿compra o desarrollo?, máximo riesgo aceptable.

FCE Fase 1. Formación de un equipo de trabajo

– Pocos recursos – Reconocimiento y posibilidad de comunicación con la alta dirección – Conocimiento de la industria, sus problemas, puntos clave, etc. – Entender la empresa, y su posicionamiento, estructura, cultura y política, posición competitiva.

FCE Fase 2. El equipo se prepara para el estudio

– Estudiar la metodología – Estudiar la técnica de entrevistas seleccionada – Familiarizarse sobre la situación de la empresa y su entorno

Metodología para generar FCE

Fase 3. Sesión introductoria con la alta administración, para: – Obtener apoyo – Obtener lista de personas a entrevistar en la siguiente fase – Obtener un primer nivel de FCE, problemas, oportunidades, etc...de todo el negocio, no sólo de informática.

FCE • ¿Cuáles son las cosas que ud. ve como FCE en su trabajo? • ¿Cuál es el área que más le perjudicaría si fallase?, ¿Dónde le molestaría más que se fallase? • Si lo aislaran del negocio 3 semanas, ¿sobre qué sería lo primero que quisiera que lo enterarán en relación al negocio?

FCE Fase 4. Sintetizar el resultado de las

entrevistas

â&#x20AC;&#x201C; Sintetizar los resultados, combinando respuestas, eliminando duplicidades y priorizando (como un primer resultado).

FCE Fase 5. Reunión de enfoque del equipo

directivo (paso clave):

– El equipo se reúne con los ejecutivos – Los ejecutivos determinarán los FCE de acuerdo a la información recolectada – Mejores resultados si la reunión es con participación abierta

RĂşbrica â&#x20AC;˘ Una rĂşbrica es un elemento que nos permite definir en forma tabular los requisitos que debe tener un producto en general y evaluarlos en base a un criterio determinado.

Ejemplo de RĂşbrica

Desarrollo de Prototipos

•

Los prototipos son una excelente herramienta para la obtención de requerimientos dado que el cliente puede ver elementos funcionales en operación del proyecto.

•

El problema es que es una técnica muy costosa, motivo por el cual su utilización está muy restringida.

Dise単o de Prototipos

Diseño de Prototipos

• Champcart

• Motor: Turbocargado, 2.65 litros V-8 • Caja de velocidad: Manual con 6 o 7 velocidades delanteras • LLantas: Bridgestone. • Peso mínimo: 1,565 libras

Diseño de Prototipos • Formula1 • Motor: Aspirado, 3 litros (183 cubic inches) V10 Turbocarga está prohibido. • Caja de velocidad: Semiautomática de 6 o 7 velocidades delanteras • Llantas: sin marca • Peso mínimo: 1,322.77 libras con conductor

Dise単o de Prototipos

Dise単o de Componentes

Diseño de Componentes • Chasis básico: $450,000. • Motor: no se venden de manera individual • Llantas: 28 llantas por evento con un costo de $1,200 por juego, alrededor de $150,000 al año • Costo equipo: 50 personas

Diseño de Componentes • Otras partes: $150,000 de refacciones y $350,000 de partes de la caja de velocidades. • Costo transporte: transporte.

$500,000

año

• Total: mínimo 2 millones, en promedio de 510 millones de dólares

Desarrollo de Prototipos

•

Los prototipos son versiones reducidas, demos o conjunto de pantallas (que no son totalmente operativos) de la aplicación pedida.

•

Esta técnica es útil cuando:

1. El área de aplicación no está bien definida (puede ser algo novedoso)

Desarrollo de Prototipos 2. El costo del rechazo de la aplicación es muy alto. 3. Es necesario evaluar primeramente el impacto del sistema en la organización. •

La técnica ayuda para visualizar la diferencia entre desarrolladores y usuarios.

Desarrollo de Prototipos

• Aunque limitado, se dispone de un sistema funcional en las primeras etapas de desarrollo. • Esta técnica se resume en: “No sé exactamente lo que quiero, pero lo sabré cuando lo vea” • Es una técnica costosa

Casos de Uso

• Otra forma de obtener requerimientos es a través de diagramas de casos de uso dentro de UML • Se recomienda utilizar diagramas de caso de uso ya que nos dan los macrorequisitos de la aplicación. Cada caso de uso debe ser especificado de manera correcta.

UML •

UML (Unified Modelling Language), lenguaje de modelado unificado. Fue desarrollado en 1997 al fusionar las metodologías de Ivar Jacobson, Jame Rumbaugh y Grady Booch.

•

Es un lenguaje visual, su premisa básica radica en que una imagen vale más que 1,000 líneas de código.

UML

• Al ser UML un lenguaje posee gramáticas y alfabetos que definen como deben de estructurarse cada una de las palabras válidas del lenguaje. • Un modelo es una representación de la realidad. No sólo se modela software sino prácticamente cualquier actividad.

UML • Es el lenguaje estándar para modelar proyectos de software. • La versión más actual del lenguaje es la 2.1 • Los métodos que se fusionaron para crear UML fueron OMT (Rumbaugh), Objectory (Jacobson) y el método Booch.

¿Por qué modelar?

• Casi el 80% de los proyectos de software fallan. • Nadie construye una casa sin un plano. • Actualmente existen muchas herramientas que auxilian el proceso de modelado como Visio, ArgoUML, Rational Rose, Together, etc.

Modelos

• Los modelos deben ser más baratos que la realidad. • Es más fácil para una persona entender un diagrama que las líneas de código fuente de un programa. • Los diagramas al igual que el texto consumen tiempo.

Modelos

• Se deben construir modelos que sean representativos para que sean útiles (imaginense hacer un documento de 100 hojas que nadie va a leeer) • UML define varios tipos de diagramas los cuales pueden ser extensibles.

MĂŠtodos Orientado a Objetos

â&#x20AC;˘ UML tiene 5 diferentes vistas con diferentes diagramas en cada una de ellas. â&#x20AC;˘ Vista usuario: representa el sistema (producto) desde la perspectiva del usuario. Se suele utilizar diagramas de casos de uso.

Métodos Orientado a Objetos • Vista estructural: modela los datos y la funcionalidad del sistema; es decir, la estructura estática (clases, objetos y relaciones). • Vista de implementación: Los aspectos estructurales y de comportamiento se representan aquí tal y como van a ser implementados.

Métodos Orientado a Objetos • Vista del comportamiento: representa los aspectos dinámicos o de comportamiento del sistema. También muestra las interacciones o colaboraciones entre los diversos elementos estructurales descritos en vistas anteriores.

MĂŠtodos Orientado a Objetos

â&#x20AC;˘ Vista del entorno: aspectos estructurales de comportamiento en el que el sistema a implementar se representa (diagramas de componentes y despliegue).

Tipos de diagramas

• Los diagramas más utilizados en UML son: • • • •

Diagramas de casos de uso Diagramas de actividades Diagramas de clases Diagramas de interacción – Diagramas de secuencia – Diagramas de colaboración

Tipos de diagramas

• Diagramas de estado • Diagramas de componentes • Otros diagramas

– Diagrama de topología del despliegue

• Los diagramas deben de reflejar lo que se pretende modelar

Diagramas de casos de uso

• Son responsables de documentar macrorequisitos del sistema.

los

• Lista de capacidades que debe brindar el sistema. • Los elementos principales son los actores y los casos de usos que en conjunto forman un escenarios.

Diagramas de casos de uso

• Se deben establecer prioridades para las capacidades del sistema. • ¿Cuál es la diferencia entre un editor de textos como Notepad y Word? • Objetivos primarios: crear, guardar e imprimir documentos de texto.

Diagramas de caso de uso

• Objetivos secundarios: guardar el archivo en formato HTML, RTF y PDF. • Los diagramas de uso sirven para mostrar detalles de implementación del sistema a usuarios finales. • Los conectores asocian a los actores y los casos de uso.

Diagramas de caso de uso

• Las líneas continuas representan una asociación y las puntuadas dependencias. • Si el conector tiene un triangulo hueco en la punta representa una generalización que es una relación de herencia. • Los estereotipos agregan detalles a una relación.

Diagramas de caso de uso • Los estereotipos más utilizados inclusión y de extensión.

son:

• Muchas herramientas no implantan UML al 100% existen muchos problemas de compatibilidad entre dichas herramientas. XMI es la descripción de un diagrama UML en XML el cual utilizan varias herramientas para exportar diagramas.

Diagramas de caso de uso

• Incluir implica una dependecia de utilización de un caso de uso. • Las notas ayudan ha aclarar los diagramas. • Extender da más detalle de dependecia de un caso de uso al cual se le agregan más capacidades.

Diagramas de caso de uso

• Las notas deben taquigráficos.

ser

como

elementos

• Se deben incluir la siguiente documentación: párrafo que describa el caso de uso, párrafo que describa cada una de las funciones primarias y secundarias, entre otros.

Diagramas de casos de uso

• Se deben detallar ejemplos de la utilización de casos de uso. • Los actores pueden ser usuarios o partes del sistema. • En general los primeros diagramas que se deben construir son los casos de uso

Diagramas de casos de uso

Preguntas frecuentes

• ¿Cuántos diagramas debo crear? No existe una respuesta específica. • ¿Debo hacer diagramas de todo tipo? No, sólo se deben utilizar los diagramas que mejor reflejen el modelado de la problemáticaoe

Preguntas frecuentes • ¿Qué tan grande debe de ser un diagrama? Entre más grande sea un diagrama mayor es la confusión. Se deben realizar diagramas bien detallados, pero no tan detallados. • ¿Cuánto texto debe complementar el modelo? Entre menos texto mejor, son como los comentarios del código fuente: pocos pero claros.

Modelado de software • Algunas recomendaciones para el modelado de software son: • No tenga a los programadores esperando los modelos. • Trabajar de una macrovista a una microvista(enfoque Top-Down).

Modelado de software • Se debe documentar en forma económica. • Si es obvio no se debe de modelar. • Hacer hincapié en la especialización. • Utilizar patrones de diseño. • Refactorizar.

Otras Técnicas •

La Ingeniería de Requerimientos comprende las actividades de obtención (captura, descubrimiento y adquisición), análisis (negociación), especificación y validación de requerimientos.

•

También establece la gestión para manejar cambios, mantenimiento y seguimiento de los requerimientos.

JAD • Joint Application Development, Desarrollo Conjunto de Aplicaciones es una técnica que consiste en realizar sesiones conjuntas entre los analistas de sistemas y los expertos del dominio. • Con esta técnica se obtienen sistemas más enfocados a la realidad, muchas metodologías nuevas se fundamentan en esta premisa.

JAD

• ¿Por qué JAD funciona?

• Por que las entrevistas son lentas, difíciles de hacer y complicadas de obtener datos. • Al ser muchos revisores del proyecto es más fácil detectar errores. • Problema: se requiere de mucha organización

ETHICS • Implementación Efectiva de Sistemas Informáticos desde los puntos de vista Humano y Técnico. • Fue desarrollada en 1979 por E. Mumford, se enfoca en los aspectos sociales que están presentes en el desarrollo del software, dado que un sistema no tendrá éxito sino es utilizado eficientemente por los empleados.

Puntos de vista • Todos los sistemas ocupan de un grupo de usuarios interesados (stakeholders), cada uno puede tener intereses diferentes, incluso en muchas casos contradictorios. • Existen métodos que toman los puntos de vistas de los usuarios para encontrar cosas en común, un ejemplo es VORD (Definición de Requerimientos Orientados a Puntos de Vista).

Puntos de vista

• VORD consiste de los siguientes pasos: • Identificación de puntos de vista • Estructuración de dichos puntos de vista • Documentación de puntos de vista (refinación) • Trazado del punto de vista (conversión a un diseño orientado a objetos)

Etnografía • Es una técnica de observación que se puede utilizar para entender los requerimientos sociales y organizacionales. Se centra en los siguientes aspectos: • La forma en la que las personas trabajan y no como el sistema los hace trabajar • Los requerimientos se derivan de la cooperación de muchas personas

Tips para la obtención de requerimientos

• Aprender de todos los documentos, formularios, informes y archivos existentes. • De ser posible se observará el sistema en acción. Se tomarán notas y dibujos. Conviene que las personas no sepan que están siendo evaluadas.

Tips para la obtención de requerimientos

• Realizar entrevistas o sesiones de trabajo en grupo para refinar los requisitos de la aplicación. • Es necesario verificar los requerimientos nuevamente hasta estar seguros

Modelado •

Es la primera fase creativa del desarrollo de proyectos. Se compone de lo qué es análisis y diseño.

•

El modelado parte de lo que es la Ingeniería de Requerimientos y devuelve un modelo que puede ser construido (implantable a través de lenguajes de programación).

Principios de Análisis • En general durante la etapa de análisis se deben especificar procesos, datos y control. • Etimológicamente análisis significa “descomponer”, debe de responder a la pregunta ¿Qué? del desarrollo de software

• En análisis estructurado se utiliza la técnica de Diagrama de Flujo de Datos para especificar procesos, Diagrama Entidad-Relación para especificar datos y diagramas de transición de estados para control. • Para el modelado de datos se recomienda definir todos los objetos (entidades) y definir sus atributos.

Principios de Análisis

Principios de Análisis • El diccionario de datos (DD) es otra forma de especificar los requerimientos de un sistema. • En general un DD son metadatos que contienen alias, donde se usa/como se usa, descripción e información adicional de los diccionarios de datos.

Principios de Análisis

• Ejemplo:

• Datos de Factura, • Datos del Cliente, • Facturación(Entradas), • Datos de Factura = NombreCliente + Domicilio + RFC+ Tel

Análisis Orientado a Objetos • Para construir un modelo de Análisis Orientado a Objetos, se usan cinco principios básicos: • Se modela el dominio de la información • Se describe la función. • Se representa el comportamiento del modelo.

Análisis Orientado a Objetos • Los modelos de datos funcional y de comportamiento se dividen para mostrar más detalles. • Los modelos iniciales representan la esencia del problema mientras que los últimos aportan detalles de la implementación.

Análisis Orientado a Objetos

• Se deben encontrar todos los objetos.

• Se debe especificar una jerarquía de clases. • Representan las relaciones objeto a objeto • Modelar el comportamiento del objeto.

Herramientas CASE • Las herramientas CASE (Ingeniería de Software Asistida por Computadora) permiten ayudar a las personas en el proceso de desarrollo de software en áreas tales como: análisis de requerimiento, depuración y pruebas.

Herramientas CASE • Existen muchas clasificaciones de las herramientas CASE, a continuación se describirán las más importantes. • U-CASE (Upper-CASE) es una herramienta que sirve de front-end durante las primeras fases del ciclo de vida: análisis y diseño.

• L-CASE (Lower-CASE) sirve de back-end durantes las últimas fases del ciclo de vida: implementación y pruebas. • I-CASE (Integrated-CASE) también llamadas workbench CASE son herramientas que ayudan en todas las fases del ciclo de vida. • Los toolkits son herramientas que solo auxilian durante una fase del ciclo de vida.

Herramientas CASE

• Tampoco se debe confundir CASE con las herramientas de gestión de proyectos que en general ayudan a la planificación y seguimiento de actividades. • Existen otras herramientas como: entornos de programación, herramientas de diseño de interfaces, herramientas de documentación, herramientas de reestructuración, ingeniería inversa, etc.

Herramientas CASE • Los componentes básicos de un sistema CASE son: los repositorio (bases de datos con algunas características del proyecto); las herramientas de diagramación y modelado, herramientas de prototipado, generación de código, generador de documentación y en la mayoría de los casos un módulo de gestión del proyecto.

Diseño de Software • El diseño es la primera parte del desarrollo de cualquier proyecto. • Etimológicamente significa componer, por lo que se obtiene la solución que habrá de implantarse. • Todas las cosas siempre tienen primero una creación mental.

• El diseño en proyectos informáticos presenta cuatro apartados: datos, arquitectura, interfaz y procedimientos. • El diseño de datos se encarga de transformar el modelo de información obtenido en el proceso de análisis en estructuras de datos. Se pueden utilizar diagramas entidadrelación pero especificados a mayor detalle.

Diseño de Software

• El diseño arquitectónico tiene la finalidad de comprobar las relaciones con los diferentes módulos o macrorequisitos del sistema (subsistemas). • El diseño de interfaz define como se comunica el software consigo mismo y hacia el exterior.

Diseño de Software • El diseño procedimental o basado en componentes consiste en la traducción de cada uno de los elementos obtenidos en la especificación de procesos, datos y transición hacia elementos implantables a través de computadoras.

Proceso del Diseño • El proceso de diseño sirve de base para la codificación del sistema. Se deben seguir algunas recomendaciones para su mejor desarrollo como las siguientes: • Se deben especificar todos los elementos explícitos e implícitos del modelo de análisis.

• El diseño deber servir de guía para que cual integrante del proyecto pueda construir y entender el software. • El diseño debe de dar una completa idea de lo que es el software. • El diseño debe presentar uniformidad e integración. Se deben definir reglas y estilos que deben seguir los miembros del equipo.

Procesos del Diseño

• El diseño debe estar estructurado, de tal forma que permita cambios. • El diseño no es escribir código, ni codificar es diseñar. • Al diseñar se deben tomar en cuenta Factores de Calidad Externos (velocidad, Fiabilidad, utilidad) y Factores de Calidad Interno (abstracción, refinamiento, modularidad).

Procesos del Diseño

• A continuación se muestra el glosario básico del diseño de proyectos de software: • Abstracción: son los niveles de resolución de problema, los cuales pueden ser alto si se especifica en lenguaje natural o bajo nivel de abstracción si tiene una implantación directa. • La abstracción puede procedimientos y control.

ser

Fundamentos del Diseño

datos,

• Refinamiento: es la base del diseño. Es un proceso de elaboración que comienza con un nivel de abstracción alto y van descendiendo sucesivamente de nivel de abstracción hasta llegar a un nivel bajo. • Durante el proceso de refinamiento se van obteniendo detalles tanto de procedimientos como de datos obteniendo mejores soluciones más fáciles de implementar.

Fundamentos del Diseño

Fundamentos del Diseño • La modularidad es el atributo de software que permite un programa sea manejable intelectualmente. • El software monolítico es muy difícil de manejar. Se debe aplicar el principio de “divide y vencerás”

Fundamentos del Diseño

• Los módulos son los componentes básicos de todo sistema y tienden a satisfacer a uno o más requerimientos. • Se han definido cinco métricas para evaluar el diseño modular: capacidad de descomposición, reutilización, capacidad de comprensión, continuidad modular y protección modular.

Fundamentos del Diseño

• La arquitectura del software hace referencia a la estructura global del sistema, dicha estructura es jerárquica en forma de módulos. • La arquitectura de software debe ayudar a definir como interactúan los componentes de software entre sí y las estructuras de los datos.

• La jerarquía de control representa dos características: visibilidad y conectividad. • La visibilidad es el conjunto de componentes de un programa que pueden ser invocados o utilizados sus datos por un componente aun de manera directa. • La conectividad indica el conjunto de componentes que son accedidos de manera directa por otros componentes.

Fundamentos del Diseño

Fundamentos del Diseño • La partición estructural de una arquitectura de software puede ser horizontal: datos, procesos y control; o bien vertical definiendo una jerarquía de módulos. • Los módulos deben programarse de tal forma que los datos no estén accesibles por otros módulos.

• El diseño modular ayuda a reducir la complejidad, facilita los cambios y ayuda a producir soluciones más sencillas. • Los tres tipos de módulos existentes son: secuencial, incremental y paralelo. • La independencia funcional se adquiere cuando se desarrollan los conceptos de modularidad, abstracción y ocultamiento de información.

Diseño Modular Efectivo

• La independencia funcional se mide en base a dos criterios: cohesión y acoplamiento. • Cohesión: es una extensión del principio de ocultamiento de información, es deseable tener una alta cohesión. Esta se obtiene cuando un módulo realiza una tarea sencilla sin depender de otros módulos

Diseño Modular Efectivo • El acoplamiento es una medida de interconexión de los módulos. Es necesario tener un bajo acoplamiento. El acoplamiento se mide en las relaciones que guardan los módulos con sus interfaces de entrada y salida. • Hay tres tipos de acoplamiento: común, de datos y control.

Diseño de Datos

• Algunas recomendaciones para el diseño de datos son: • Definir todas las posibles operaciones a realizar sobre los datos. • Se deben refinar las estructuras de datos hasta tener representaciones de bajo nivel.

Diseño de Datos

• Se deben desarrollar bibliotecas útiles para la manipulación de datos. • El lenguaje de implementación soportar tipos de datos abstractos.

debe

• Se debe tener cuidado a la hora de diseñar diccionarios de datos, para que no se tengan “basureros de datos” en lugar de almacenes de datos.

Diseño Arquitectónico

• El concepto de Arquitectura de Software tiene mucho tiempo de antigüedad, pero no fue hasta la década de los 1990s que comenzó a utilizarse de manera formal. • Analizando los sistemas se puede observar que existen patrones que se repiten conformando lo que se conoce como estilos arquitectónicos.

• Un estilo arquitectónico define un conjunto de familias de patrones de software con una determinada estructura y restricciones. • Generalmente los patrones de diseño y arquitectura definen soluciones para medios repetitivos. • La arquitectura de software es una abstracción del sistema que nos permite ver su estructura y su relaciones.

Diseño Arquitectónico

Diseño Arquitectónico • Para el desarrollo del Diseño Arquitectónico se recomiendan seguir los siguientes pasos: • Estructuración del sistema • Modelado de control • Descomposición modular

Diseño Arquitectónico

• La Arquitectura de Flujo de Datos parte del DFD para obtener una arquitectura del sistema: • Se establece el tipo de flujo de información • Se indican los límites del flujo • Se convierte el DFD en una estructura del programa

Diseño Arquitectónico

• Se define la jerarquía de control mediante particionamiento. • Se refina la estructura resultante utilizando heurísticas de diseño. • La Arquitectura Centrada en Datos tiene como componente principal un repositorio, del cual surgen los demás componentes.

Diseño Arquitectónico

• Las Arquitecturas Estratificadas son de las más utilizadas en la actualidad, dado que dividen las actividades y responsabilidades de sistemas por capas. • El software más elaborado como los sistemas operativos, software de base, sistemas distribuidos y otros maneja variantes de esta arquitectura.

Diseño Arquitectónico • El diseño se debe refinar realizando cada uno de los siguientes pasos: • Desarrollar una descripción procedimiento para cada módulo.

del

• Desarrollar una descripción de la interfaz para cada módulo.

Diseño Arquitectónico • Se definen las estructuras generales y globales.

• Se anotan todas limitaciones/restricciones del sistema.

datos las

• Se debe refinar el diseño hasta que esté completo. Se recomienda completar la arquitectura con el Diseño de Interfaces.

Diseño de Interfaz de Usuario

• El diseño de interfaces se refiere al estudio de las relaciones entre los usuarios y las computadoras para que un sistema se pueda ejecutar. • El diseño de una interfaz puede definir el éxito de cualquier proyecto, ya que la utilización de cualquier interfaz de usuario depende de factores humanos.

Diseño de Interfaces de Usuario • Existen algunas reglas de oro para el buen diseño de Interfaces de Usuario: • Dar el control al usuario • Reducir la carga de memoria del usuario • Construir una interfaz consecuente

• Existen cuatro modelos diferentes para el desarrollo de interfaces: • Modelo de diseño: que consiste en representar el software de acuerdo a los datos, arquitectura, interfaz y procedimiento. • Modelo de Usuario: Representa el perfil del usuario (edad, cultura, etnia, educación, etc.)

Diseño de Interfaces de Usuario

• Existen tres tipos de usuario: Principiantes, Esporádicos y Frecuentes. • La percepción del sistema (modelo de usuario): es la idea que tienen los usuarios sobre la posible interfaz del sistema. • La imagen del sistema es un modelo que intenta mezclar lo que es la estructura del sistema con analogías de la vida real.

Diseño de Interfaces de Usuario

Diseño de Interfaces de Usuario • Las fases del proceso del desarrollo de interfaces de usuario son: • • • •

Análisis de usuarios, tareas y entornos Diseño de la interfaz Implementación de la interfaz Validación de la interfaz

Diseño de Interfaces de Usuario

• Se deben seguir recomendaciones:

las

siguientes

• Establecer los objetivos e intenciones de cada tarea. • Hacer correspondencia entre cada objetivo con una secuencia de interacción. • Especificar la secuencia de acciones de tareas y subtareas.

• Se debe indicar el estado del sistema • Se deben definir mecanismos de control • Se debe mostrar la forma en como los mecanismos de control afectan el estado del sistema. • Se debe indicar la forma en que el usuario interpreta el estado del sistema a partir de la información presente en la interfaz.

Diseño de Interfaces de Usuario

Diseño de Interfaces de Usuario • Los principales problemas que se presentan al diseñar una interfaz de usuario son: • • • •

El tiempo de respuesta del sistema Los servicios de ayuda al usuario La manipulación de información de errores El etiquetado de órdenes

• También llamado de Componentes, se debe de desarrollar cuando se haya terminado el diseño de datos, interfaz y arquitectura. • El objetivo de este diseño es tener un modelo de solución que sea fácil de implementar en lenguajes de programación. • El diseño de procedimientos se hace de manera estructurada pero bien podría hacerse con otro paradigma.

Diseño Procedimental

• Se pueden utilizar mecanismos como los diagramas de flujo, los diagramas de caja (NS-Chapin), Lenguaje de Diseño de Programación (Pseudocódigo). • El diseño procedimental debe de ser: • Simple (leer, usar y entender) • Modular • Fácil de editar

Diseño Procedimental

Diseño Procedimental • Legible para la computadora • Representar los datos del problema • El diseño procedimental es la etapa más importante del diseño para la fase de construcción del proyecto dado que el modelo que aquí se genere debe de estar libres de errores.

• Existen varias formas de documentación de la etapa del diseño, a continuación se muestra la que se utilizará en el curso: • • • • •

Ámbito Diseño de Datos Diseño Arquitectónico Diseño de Interfaz Diseño Procedimental

Documentación del Diseño

Documentación del Diseño • Referencias cruzadas de requisitos • Recursos de prueba • Notas especiales • Ámbito:

– Objetivos – Principales requisitos de Software – Restricciones de Diseño y Limitaciones

Documentación del Diseño • Diseño de Datos:

– Objetos de Datos – Estructuras de archivos y base de datos (estructura lógica, métodos de acceso, datos)

• Diseño arquitectónico:

– Revisión de datos y flujos de control – Estructura del Programa

Documentación del Diseño

• Diseño de Interfaz:

– Especificación HMI – Normas de diseño de la HMI – Diseño de la interfaz externa (con datos y sistemas externos) – Normas de diseño de la interfaz interna.

• Diseño procedimental:

– Los pasos siguientes se deben hacer para cada módulo.

Documentación del Diseño

– Descripción del proceso – Descripción de la interfaz – Descripción del lenguaje de diseño – Módulos usados – Estructuras de datos internas

• Referencias cruzadas de requisitos: esta sección es opcional, sirve para llevar el control de donde se están satisfaciendo los requerimientos del modelo de análisis.

Documentación del Diseño • Recursos de prueba:

– Directrices para las pruebas – Estrategias de integración – Consideraciones especiales

• Notas especiales: – Apéndices

Heurísticas del Diseño • A continuación se muestra un conjunto de heurísticas a seguir para obtener mejores resultados: • Evaluar la primer iteración de la estructura de programa para reducir el acoplamiento y mejorar la cohesión. – Explosión – Implosión

Heurísticas del Diseño • Intentar minimizar las estructuras con un alto grado de salida; esforzarse por la entrada a medida que aumenta la profundidad. • Mantener el ámbito del efecto de un módulo dentro del ámbito de control de ese módulo. • Evaluar las interfaces de los módulos para reducir la complejidad, la redundancia, y la consistencia.

Heurísticas del Diseño • Definir módulos cuya función pueda predecir, pero evitar módulos que sean demasiado restrictivos. • Intentar conseguir módulos de entrada controlada evitando conexiones patológicas.

• Se recomienda las siguientes acciones para tener un diseño óptimo: • Desarrollar y refinar la estructura del programa sin preocuparse de la optimización. • Usar herramientas CASE que simulen el rendimiento en tiempo de ejecución para aislar áreas de ineficiencia.

Optimización del Diseño

• Durante iteraciones posteriores del diseño, seleccionar los módulos sospechosos de “devorar tiempo” y desarrollar cuidadosamente procedimientos que mejoren la eficiencia en el empleo de tiempo. • Codificar en un lenguaje de programación apropiado.

Optimización del Diseño • Instrumentar el software para aislar módulos que consuman mucho tiempo de procesador. • Si es necesario, rediseñar o recodificar en lenguaje máquina para mejorar la eficiencia.

Diseño Orientados a Objetos • Consiste en representar un modelo de datos que pueda ser fácilmente implantable con algún lenguaje de programación orientado a objetos. • Los objetos son componentes potencialmente reutilizables, lo que hace que el software sea más fácil de mantener.

Diseño Orientado a Objeto • El proceso general para el diseño orientado a objetos tiene varias etapas: 1. Comprender y definir el contexto y los modos de utilización del sistema. 2.Diseñar la arquitectura del sistema. 3.Identificar los objetos principales en el sistema.

DiseĂąo Orientado a Objetos 4. Desarrollar los modelos de diseĂąo. 5. Especificar las interfaces de los objetos. â&#x20AC;˘ No es un proceso sistematizado al 100%, por lo que necesita refinarse con varias iteraciones.

Diseño Orientado a Objetos • El primer paso consiste en identificar los tipos de relaciones definidos en el sistema, los cuales pueden ser internos y externos. Estas relaciones pueden ser dos: • El contexto del sistema: es un modelo estático que describe a los otros sistemas en ese entorno.

• El modelo que el sistema utiliza: es un modelo dinámico que describe cómo interactúa el sistema con su entorno. • Con el diseño de contexto se puede crear fácilmente el diseño arquitectónico de la aplicación. • Existen diversas técnicas para identificar objetos:

Diseño Orientado a Objetos

• Utilizar un análisis gramatical de la descripción en lenguaje natural de un sistema. • Utilizar entidades tangibles (cosas). • Utilizar un enfoque de comportamiento. • Utilizar un análisis basado en escenarios.

Diseño Orientado a Objetos

• Existen dos tipos de modelos de diseño para describir un diseño orientado a objetos: • Modelos Estáticos. • Modelos Dinámicos. • Ejemplos de algunos modelos:

Diseño Orientado a Objetos

• Los modelos de subsistemas • Los modelos de secuencia

• Los modelos de máquinas de estado • La encapsulación de las clases hace que los sistemas evolucionen de forma rápida y sencilla.

Métodos Orientado a Objetos

• Existen diversas metodologías para la realización de análisis y diseño orientado a objetos como: • Método de Booch: abarca un microproceso de desarrollo y un macroproceso de desarrollo. • Método OMT (Rumbaugh)

Métodos Orientado a Obejtos • Objectory (Jacobson) • Método de Coad-Yourdon • Método UML:

Diagramas de actividades • Es la versión UML de un diagrama de flujo. • Se usan para analizar los procesos y realizar la ingeniería de los mismos. • Es una excelente analizar problemas.

herramienta

para

Diagramas de actividades • Son diagramas que representan carácterísticas de los procesos.

las

• Estos diagramas deben facilitar implementación del sistema.

• Van enfocados a los expertos del dominio (programadores y analistas).

Diagrama de actividades • Pueden modelar procesos lineales y paralelos. • Los diagramas deben ser más simples que detallados. • Los elementos principales son: nodo inicial, flujo, actividades, conectores.

Diagramas de actividades • Se pueden utilizar clavijas para conectar dos nodos de acción. • Los nodos de decisión son importantes para bifurcar el flujo de actividades. • Los nombres y los verbos nos sirven para determinar las clases y los métodos.

Diagramas de actividades • Los casos de uso son candidatos a desarrollar diagramas de actividades. • Las condiciones previas y posteriores se manejan con el uso de guardianes. • Los nodos de decisión también sirven para fusionar diversos flujos en uno solo.

Diagramas de actividades • Los carriles sirven para delimitar quien es el responsable de una serie de actividades. • Los carriles formalmente se llaman partición de actividades y puede haber varios siempre y cuando no se encimen. • Se puede modelar el tiempo a través de señales.

Diagramas de Actividades

Diagramas de clases â&#x20AC;˘ Se usan para mostrar las clases de un sistema y las relaciones entre ellas. â&#x20AC;˘ Muestran la vista estĂĄtica del sistema; no describen los comportamientos ni la forma en como interactuan las clases del sistema.

Diagramas de clases • Los elementos del lenguaje son unos rectángulos denominados clases y los conectores representan las relaciones. • Las clases pueden tener comportamientos y atributos. Lo difícil no es encontrar las clases sino definir sus relaciones

Diagramas de clases • Un diagrama de objetos es similar a un diagrama de clases pero representa un comportamiento dinámico. • Los objetos se distinguen al subrayar el nombre de la clase. • Las interfaces son clases abstractas puras.

Diagramas de clases • Las interfaces se usan cuando las partes de las cosas tienen facetas semánticamente similares pero no tienen genealogía relacionada. • Se utiliza el estereotipo interface. Los tipos de datos pueden variar dependiendo de la implementación.

Diagramas de clases • El símbolo + se usa para describir datos públicos. El símbolo - para datos privados y # un dato no es ni público ni privado (protegido). • Para acceder a datos privados y/o protegidos se deben utilizar métodos get/set

Diagramas de clases • Los atributos funcionan como asociación. La multiplicidad de las relaciones es importante. • Si los valores superiores e inferiores de las relaciones son iguales (1..1) se pone un solo número (1).

Diagramas de clases • Es común hablar de elementos opcionales, obligatorios, de un solo valor y valores múltiples. • El 80% de los diagramas de clase utilizan relaciones simples. • Si existe una flecha en la asociación se dice que ésta es dirigida o direccional.

Diagramas de clase • La agregación se representa con diamante hueco; mientras que composición es un diamante relleno.

un la

• La generalización o herencia se refiere a una relación del tipo es un. • En una relación de herencia la clase hijo hereda las carácterísticas de la clase padre.

Diagramas de clase • Las relaciones de realización se utilizan en interfaces para definir que la clase hija implementará esa interfaz. Se utiliza una línea punteada con un diamante parecido a la herencia. • Las relaciones de dependencia se dan entre dos clases denominadas cliente y proveedor. Se representa con una línea punteada con flecha sencilla.

Diagramas de clase

• Los paquetes tienen la apariencia de una carpeta de archivos. Se usa para representar un nivel más avanzado de abstracción. Se utilizan para organizar las clases, generalmente representan un espacio de nombres. • Los espacios de nombres solucionan el problema de tener clases diferentes con el mismo nombre.

Diagramas de clase

• Algunas herramientas soportan la documentación del modelo, pero no forma parte del estándar. • UML tiene datos primitivos: Integer, Boolean, String y UnlimitedNatural, pero se pueden utilizar otros tipos de datos definidos por el estereotipo primitivo, solo hay que definir sus componentes y sus operadores.

Diagramas de clases • Los espacios de nombre se anteponen al de la clases con el operador de alcance: :: • Existen dos modalidades para el desarrollo de software orientado a objetos: consumo (Visual Basic) y Producción (Visual C++). • La técnica de nombres son clases, verbos son métodos sólo funciona en el 20% de los casos.

Diagramas de clases

â&#x20AC;˘ Se recomienda realizar un anĂĄlisis de dominio ya que nos ayuda a encontrar clases frontera, de control y entidad. â&#x20AC;˘ Las clases frontera interconenctan elementos del exterior con elementos del interior. Las clases de entidad representan datos (generalmente persistentes). Las clases de control representan interacciones entre el sistema.

Diagramas de clases • La refactorización y los patrones de diseño ayudan a mejorar los diagramas de clases. • La herencia múltiple se puede modelar en UML pero no es recomendable hacerlo. Es mejor usar la composición o herencia de interfaces. • “El mal se encuentra en los detalles”.

Diagramas de Clases

Diagramas de secuencia • Muestran la parte dinámica del sistema. • Muestran los mensajes que se envían las clases con respecto al tiempo. • Los diagramas de secuencia muestran un orden a través del tiempo. • Un diagrama de secuencia es más fácil de leer que uno de colaboración.

Diagramas de secuencia • Existen muchos diagramas en UML que resultan redundantes, ya que dicen exactamente lo mismo pero en diferente forma. • Los elementos esenciales son las líneas de vida y los mensajes. • La línea de vida representa un ejemplo de clase

Diagramas de secuencia • Las líneas de vida pueden ser actores u objetos. • La activación de una línea de vida se hace a través de un rectangulo sobre la línea de vida. Un objeto puede crearse y destruirse varias veces dentro de la ejecución de un sistema.

Diagramas de secuencia â&#x20AC;˘ Los mensajes forman una parte importante de este diagrama. Si se tiene una flecha triangular representa un mensaje sĂncrono, si se tiene una flecha abierta se representa un mensaje asĂncrono, los mensajes de retorno se representan con flechas punteadas, mientras que un mensaje anidado inicia y termina en la misma lĂnea de vida.

• Los marcos de interacción o fragmentos combinados son nuevos en UML 2. • Son regiones rectangulares que se usan para organizar los diagramas de interacción. • Los marcos de interacción más comunes son: alt, bucle, neg, opt, par, ref, regio rod

Diagramas de secuencia

Diagramas de secuencia • En un futuro no tan lejano, los diseños deberán ser tan detallados como los circuitos eléctricos. • En algunos casos es mejor usar diagramas de colaboración, debido a la sencillez de su diseño.

Diagramas de Secuencia

Diagramas de interacción • También muestran la parte dinámica del sistema. • Organizan las clases y los mensajes en forma espacial. Como no lleva ordenación del tiempo los mensajes se enumeran. • Los diagramas de secuencia e interacción son complementarios y en algunos casos no es aconsejable utilizar ambos.

Diagramas de colaboración • También se les llama comunicación en UML 2.

diagrama

• Los elementos son un rectángulo llamado papel clasificador que representa los objetos, conectores y una secuencia que indica los mensajes. En UML la secuencia se numera como 1, 1.1, 1.2, … en lugar de 1, 2, 3

Diagramas de colaboración • Un diagrama de interacción se puede pasar a código. Los objetos son instancias de clases y los mensajes son métodos, los cuales se codifican en la clase del receptor no del llamador. • En diagramas donde existen muchos mensajes se necesitan de más notas para poder explicar el diagrama.

Diagramas de colaboraci贸n

Diagramas de estado â&#x20AC;˘ Muestra el estado cambiante de un objeto. â&#x20AC;˘ UML es un lenguaje relativamente sencillo ya que utilizando poco vocabulario se puede realizar la mayorĂa del modelado de un sistema.

Diagramas de estado • Sirven para representar máquinas de estados (e.g. autómatas). • Son ideales para representar procesos de red y de tiempo real. • La creación de diagramas de interfaces gráficas de usuarios no es parte del estándar UML.

Diagramas de estado • Los diagramas de estado y actividades comparten mucha de la simbología por lo que se les suele confundir con frecuencia. • Los estados son activos cuando se ejecutan su actividad de entrada. Se vuelven inactivos después de ejecutar su actividad de salida

Diagramas de estado • Las actividades comunes son algo que sucede de manera instantánea; mientras que una actividad inicia con el prefijo “hacer/” es una actividad de hacer. • Un estado simple no está dividido en regiones. En un estado compuesto cada región representa una subactividad.

Diagramas de estado • Las transacciones son líneas dirigidas que conectan estados. Pueden ocurrir en base a algún mecanismo de disparo. • Las máquinas de estado de protocolo se utilizan para describir interfaces.

Diagramas de estado

Diagramas de componentes • Muestra los subsistemas del producto final. • No es un diagrama ampliamente utilizado en UML. • Existen dos métodos para el diseño basado en componentes: diseño componentes-interfaz (arriba abajo) y a partir de clases.

Diagramas de componentes • El símbolo de componente cambió en UML 2 a un diagrama más simple. • Se utiliza generalmente para modelar sistemas muy grandes. • Sistemas basados en red y distribuidos pueden modelarse bien con este diagrama.

Diagrama de despliegue • Se utiliza para modelar la forma en como lucirá el sistema cuando se ponga en uso. • Los nodos representan componentes físicos que pueden ser computadoras, sistemas operativos, entornos, servidores, etc. • Ayudan al proceso de instalación de un sistema

Diagrama de despliegue • Los artefactos son las cosas que se están desplegando. Usan el estereotipo artefacto y pueden ser achivos exe, dll, HTML, .jar, scripts, etc. • Dentro de cada nodo se suele describir algunas carácterísticas propias.

多Preguntas, dudas y comentarios?