sintesis

¿Por qué?

  • Inefectividad, ineficacia y/o ineficiencia, del Proyecto Software

    • porque tiene malas variables en su economía:

      • ámbito incumplido y/o

      • tiempo incumplido y/o

      • coste incumplido;

    • porque tiene mala calidad del software, fiabilidad, usabilidad, interoperatividad, seguirdad, …​ (-ilities)

    • porque tiene mala mantenibilidad

      • viscoso, porque no se puede entender con facilidad y/o

      • rígido, porque no se puede cambiar con facilidad y/o

      • frágil, porque no se puede probar con facilidad y/o

      • inmovil, porque no se puede reutilizar con facilidad y/o

    • porque tiene complejidad arbitraria

davidProyectoImplantacionDiseñoMal

arbolNoMantenible
Soy el cliente de la aplicación que deseo Eres el jefe de proyecto de la aplicación Soy un miembro del equipo directivos de tu empresa

  • ¿Sabrías qué y cómo preguntarme, en qué orden y hasta qué nivel de detalle y cuándo?

  • ¿Cuál sería el formato adecuado del resultado de las reuniones?

  • ¿Cómo repartirías las tareas de requisitos entre las personas del equipo de desarrollo? ¿Con cuántas personas empezarías?

  • ¿Por qué parte comenzarías, continuarías y terminarias la producción de código?

  • ¿Qué medidas aplicarías para obtener la calidad del software adecuada para facilitar la depuración de errores, la mantenibilidad corrective, perfective o adaptativa?

  • ¿Cómo repartirías las tareas de producción entre las personas del equipo de desarrollo?

  • ¿Cuánta gente incorporarías?

  • ¿Sabrías justificarme mes a mes qué tiempo se tardará en terminar el proyecto con el personal asignado en distintos momentos de proyecto?

  • ¿Sabrías justificarme el grado de satisfacción del cliente durante el transcurso del proyecto?

  • ¿Sabrías justificarme cuántas personas añadir al proyecto para reducir el tiempo de desarrollo?

¿Qué?

  • Disciplina de Diseño: flujo de trabajo (realización de casos de uso que incluye trabajadores, actividades y diagramas) cuyo principal propósito es desarrollar modelos enfocados sobre los requisitos no funcionales y el dominio de la solución y preparar para la implementación y pruebas del sistema

¿Para qué?

  • Efectividad, eficacia y eficiencia, del Proyecto Software

    • porque tiene buenas variables en su economía:

      • ámbito cumplido y

      • tiempo cumplido y

      • coste cumplido;

    • porque tiene buena calidad del software, fiabilidad, usabilidad, interoperatividad, seguirdad, …​ (-ilities)

    • porque tiene buena mantenibilidad

      • fluido, porque se puede entender con facilidad y/o

      • flexible, porque se puede cambiar con facilidad y/o

      • fuerte, porque se puede probar con facilidad y/o

      • reusable, porque se puede reutilizar con facilidad y/o

    • porque tiene complejidad necesaria

davidProyectoImplantacionDiseño

arbolMantenible
Objetivos …​ desde la disciplina de Análisis

  • Ser capaz de visualizar y razonar sobre el diseño mediante el uso de una notación común

  • Adquirir un conocimiento en profundidad de los temas sobre los requisitos no funcionales y limitaciones relacionadas con los lenguajes de programación, la reutilización de componentes, sistema operativo, tecnologías de distribución y concurrencia, tecnologías de bases de datos, tecnologías de interfaz de usuario, las tecnologías de gestión de transacciones, etc.
Objetivos …​ para la disciplina de Implementación

  • Crear una abstracción sin fisuras de la implementación del sistema, en el sentido de que la implementación es un refinamiento sencillo del diseño mediante la cumplimentación de la "carne", pero sin cambiar la estructura. Esto permite el uso de técnicas como la generación de código e ingeniería de ida y vuelta entre el diseño y la implementación

  • Crear una entrada apropiada como punto de partida para las actividades de la implementación posterior mediante la captura de requisitos sobre los distintos subsistemas, interfaces y clases
Objetivos …​ para la disciplina de Gestión

  • Captura los interfaces principales entre los subsistemas en las fases tempranas del ciclo de vida del software. Esto es útil cuando razonamos sobre arquitectura y cuando usamos las interfaces como instrumentos de sincronización entre los diferentes equipos de desarrollo

  • Ser capaz de descomponer el trabajo de implementación en partes más manejables gestionados por diferentes equipos de desarrollo, posiblemente de forma concurrente

¿Cómo?

Actividades

design

Introduccion

Diseñar la Arquitectura

designArchitecture

DiseñarArquitectura
Identificar los nodos y configuraciones de red

  • Las configuraciones de red físicas a menudo tienen un impacto importante en la arquitectura del software, incluyendo las clases activas requeridas y la distribución de funciones entre los nodos de la red. Cada configuración de la red debe ser representado en los diagramas de despliegue separados con nodos, tipo de conexiones, protocolos, anchos de banda, disponibilidad, calidad, …​
height32
height32
height32
Identificar Subsistemas y sus Interfaces

  • Identificar subsistemas específicos de la aplicación y de aplicación general. Si encontramos durante el análisis una descomposición de paquetes de análisis apropiado, podemos usar estos paquetes tanto como sea posible e identificar subsistemas en el modelo de diseño. Sin embargo, esta identificación inicial de los subsistemas será refinado ligeramente durante el diseño por asuntos relacionados con el diseño, implementación y despliegue del sistema

  • Identificar subsistemas Middleware y Software de Sistemas. El software del sistema y Middleware es la base de un sistema, ya que todas las funciones se apoyan en la parte superior de un software como sistemas operativos, sistemas de gestión de bases de datos, software de comunicación, kits de diseño de interfaz gráfica de usuario, …​
height32
height32
height32
height32

  • Un refinamiento de la descomposición inicial, en comparación con los paquetes de análisis, puede ser necesaria cuando:

    • Parte de paquete de análisis se proyecta sobre un mismo subsistema

    • Los paquetes de análisis no reflejan una división apropiada de trabajo

    • Algunas partes del paquete de análisis se realizan con productos de software reutilizados

    • Los paquetes de análisis no reflejan la incorporación de un sistema heredado
height32

  • Los paquetes de análisis no están preparados para un despliegue sencillo en nodos

  • Definición de dependencias del subsistema.

    • Las dependencias entre subsistemas deben ser definidos si su contenidos tienen relaciones entre sí. La dirección de la dependencia debe ser la misma que la dirección de la relación

  • Identificar Interfaces de Subsistemas.

    • Si hay un paquete de análisis que se puede trazar desde un subsistema, entonces cualquier clase de análisis que se hace referencia desde el exterior del paquete puede implicar un candidato como su interfaz
height32
height32
height32
Identificar Clases arquitectónicas significativas de Diseño

  • Identificar las Clases de Diseño desde de Clases de Análisis.

    • Algunas Clases de Diseño pueden esbozarse inicialmente desde las Clases de Análisis de gran importancia arquitectónica como se encontraron durante el análisis.

    • Además, sus relaciones también.

  • Identificar Clases Activas.

    • El arquitecto también identifica las clases activas que requiere el sistema teniendo en cuenta los requisitos de concurrencia en el sistema

  • Identificar Mecanismos de Diseño Genérico.

    • Estudiamos requisitos comunes, tales como las prescripciones especiales identificadas durante el análisis

Diseñar Casos de Uso

designUseCase

DiseñarCasoDeUso
Identificar las clases de diseño de participantes

  • Estudiar las clases de análisis que participan en la correspondiente realización de casos de uso.

  • Identificar las clases de diseño que trazan a esas clases de análisis

  • Estudiar las necesidades especiales de la correspondiente realización de casos de uso.

  • Identificar las clases de diseño que realice esas necesidades especiales, como los mecanismos genéricos

  • Si alguna clase de diseño para el diseño del caso de uso específico sigue desaparecida, el ingeniero de caso de uso debe comunicar ésto a los arquitectos o los ingenieros de componentes

  • Recoge las clases de diseño que participan en la realización de un caso de uso en un diagrama de clases asociado con la realización
diagramaDisenyoCasoUso
Describir las Interacciones de Objetos de Diseño

  • Utilizando diagramas de secuencia que contienen las instancias de actor participante, objetos de diseño, y la transmisión de mensajes entre ellos:

  • El caso de uso es invocado por un mensaje de una instancia actor para un objeto de diseño

  • Cada clase de diseño identificado en la etapa anterior debe tener al menos un objeto de diseño participando en un diagrama de secuencia

  • Los mensajes se envían entre las “vidas” de objeto para la realización del caso de uso. Un mensaje puede tener un nombre temporal que se convertirá en el nombre de una operación después de que ha sido identificado por el ingeniero componente responsable de la clase del objeto receptor

  • El diagrama de secuencia debe ser el foco principal debido a que la realización-diseño del caso de uso es la entrada principal cuando se implementa el caso de uso. Es importante comprender el orden cronológico de transmisión de mensajes entre objetos

  • Como detallamos los diagramas de interacción, lo más probable es encontrar nuevos caminos alternativos que el caso de uso puede tomar.

  • Mientras se añade más información, el ingeniero de casos de uso a menudo descubrirá nuevas excepciones que no fueron pensadas durante la captura de requerimientos o el análisis. Estos tipos de excepciones incluyen:

    • Manejo de los tiempos de espera cuando los nodos o conexiones dejan de trabajar

    • Entradas erróneas que los actores humanos y máquinas podrían proporcionar
diagramaDisenyoCasoUsoSecuencia
Identificar los Subsistemas e Interfaces Participantes

  • A veces, sin embargo, es más apropiado para diseñar un caso de uso en términos de subsistemas participantes y/o de sus interfaces.

  • Por ejemplo, durante el desarrollo top/down, puede que sea necesario para capturar los requisitos de los subsistemas y sus interfaces con anterioridad a que su interior se ha diseñado.

  • O, en algunos casos debe ser fácil substituir un subsistema y su diseño interno específico con otro subsistema que tiene otro diseño interno.

  • En tales casos, la realización-diseño de un caso de uso de puede ser descrito en varios niveles en la jerarquía de subsistema:

    • Utilice este diagrama de clases para mostrar las dependencias entre los subsistemas y cualquier interfaz que se emplee en la realización del caso de uso

    • Estudiar las clases de análisis que participan en la realización del análisis de caso de uso correspondiente.

    • Identificar los paquetes de análisis que contienen esas clases de análisis, si los hay. Luego, identificar los subsistemas de diseño que trazan a los paquetes de análisis

    • Estudiar las necesidades especiales de la realización del análisis de caso de uso correspondiente.

    • Identificar las clases de diseño que realizan esas necesidades especiales, si las hay. Luego, identifique el subsistema de diseño que contiene las clases

    • Recoger los subsistemas que participan en un la realización del caso de uso en un diagrama de clases que se asocia con la realización.
Describir las Interacciones entre Subsistema

  • Tenemos que describir cómo los objetos de sus clases contenidas interactúan en un nivel de subsistema.

  • Esto hace mediante el uso de los diagramas de secuencia que contienen los participantes instancia del actor, subsistemas, y transmisiones de mensajes entre ellos, al igual que antes, con las siguientes diferencias:

    • Las líneas de vida en los diagramas de secuencia denotan subsistema en lugar de objetos de diseño

    • Cada subsistema identificado debe tener al menos una línea de vida en el diagrama de secuencia

    • Si se asigna un mensaje a una operación de una interfaz, puede ser apropiado proporcionar las operaciones para calificar el mensaje con la interfaz
Capturar los Requisitos de Implementación

  • En este paso, capturamos la realización en un caso de uso con todos los requisitos, como con los requisitos no funcionales, que se identifican en el diseño, pero que deben ser tratados en la implementación

Diseñar Clases

designClass

DiseñarClase
Describir la Clase de Diseño

  • El diseño de las Clases de Vista es dependiente de las tecnologías de interfaz específicas en uso

  • El diseño de las Clases de Entidad que representan la información persistente a menudo implica el uso de una tecnología de bases de datos específica. Puede haber muchos problemas de diseño que participan en la adopción de esta estrategia, sobre todo en la proyección del diseño orientado a objetos a un modelo de datos relacional

  • Diseñar Clases de Control es delicada. Ya que encapsulan secuencia, la coordinación de otros objetos y la pura lógica de negocio, la siguiente necesidades deben ser tenidas en cuenta:

    • Cuestiones de distribución. Si la secuencia debe ser distribuida y administrada entre varios nodos diferentes en una red, las clases de diseño separadas en distintos nodos podrían ser necesarias para las realización de las clases de control

    • Los problemas de rendimiento. Puede que no sea justificable tener clases de diseño separadas realizando la clase de control. En cambio, la clase de control podría ser realizado por las mismas clases de diseño que están realizando algunas clases de vistas y/o entidad relacionada

    • Cuestiones de transacción. Las clases de control a menudo encapsulan una transacción. Su diseño correspondiente debe entonces incorporar cualquier tecnología de gestión de transacciones existente
Identificar Entradas de Operaciones Importantes

  • Serán las responsabilidades de cualquier clase de análisis que traza la clase de diseño. Una responsabilidad implica a menudo una o varias operaciones.

  • Por otra parte, si se describen las entradas y salidas de las responsabilidades, las pueden utilizar como un primer esbozo de parámetros formales y valores resultantes de operación

  • Incorporar algún mecanismo de diseño genérico o tecnología para los requisitos especiales de cualquier clase de análisis que traza la clase de diseño
Identificar Atributos

  • Tenga en cuenta los atributos de cualquier clase de análisis que trazan la clase de diseño.

  • Los tipos de atributos disponibles están limitadas por el lenguaje de programación. Cuando elija un tipo de atributo, intente volver a utilizar uno existente

  • El valor de un atributo no puede ser compartido por varios objetos de diseño. Si esto es necesario, el atributo debe definirse como una clase separada

  • Si una clase de diseño se vuelve demasiado complicada de entender debido a sus atributos, algunos de estos atributos pueden ser separados en clases

  • Si hay muchos o complejos atributos en una clase, puede ilustrar esto en un diagrama de clases separadas que muestran solamente los atributos compartimentados
Identificar Asociaciones y Agregaciones

  • El número de relaciones entre las clases debe ser minimizado:

  • Considerar las asociaciones o agregaciones implicadas en las clase de análisis correspondientes

  • Matizar las multiplicidades de la asociación, nombre de rol, clases de asociación, roles ordenados, roles calificados, y asociaciones n-arias de acuerdo con el apoyo del lenguaje de programación en uso.

  • Refinar la navegabilidad de asociaciones. Tenga en cuenta los diagramas de interacción en el que la asociación es empleaba. La dirección de la transmisión de mensajes entre objetos de diseño implica la navegabilidad correspondiente de asociaciones entre sus clases

  • Identificar generalizaciones que se deben utilizar con la misma semántica como se define en el lenguaje de programación
Describir Métodos.

  • El método se puede especificar utilizando lenguaje natural o usando pseudocódigo si es lo adecuado. Sin embargo, la mayoría de las veces los métodos no se especifican en el diseño
Describir Estados

  • Algunos objetos de diseño están controlados por el estado, lo que significa que su estado determina su comportamiento cuando reciben el mensaje.

  • En tales casos, es significativo utilizar un diagrama de estados para describir las diferentes transiciones de estados del objeto de diseño
Gestionar los Requisitos Especiales.

  • Todos los requisitos que no han sido considerados en los pasos precedente se deben gestionar

  • Al gestionar estos requisitos, utilice todos los mecanismos genéricos de diseño propuestas por el arquitecto si es posible. Sin embargo, puede ser apropiado para posponer la manipulación de algunos requisitos hasta la implementación

Diseñar Subsistema

designSubsystem

DiseñarSubsistema
Mantener las dependencias de los Subsistemas Mantener las interfaces proporcionadas por el subsistema Mantener los Contenidos del Subsistema

  • Asegurar que el subsistema es lo más independiente posible de otros subsistemas y/o de sus interfaces

    • Si un subsistema proporciona una interfaz, deben declararse dependencias (usos) hacia esa interfaz. Es mejor ser dependiente de una interfaz que de un subsistema dado que subsistema podría sustituir con otro subsistema que contiene otro diseño interno, mientras que la interfaz no necesita ser sustituida en ese caso

  • Asegurar que el subsistema proporciona las interfaces correctas

    • A pesar de que las interfaces se describen por los arquitectos, pueden necesitar ser refinadas por el ingeniero de componentes según el modelo de diseño evoluciona con los casos de uso.

    • El enfoque de mantener interfaces y sus operaciones es similar al enfoque de mantener clases de diseño y sus operaciones

  • Asegurar que el subsistema cumple su propósito ofreciendo una correcta realización de las operaciones tal como se define por las interfaces que presta

    • Incluso si el contenido del subsistema se perfila por el arquitecto, es posible que tenga que ser refinado por el ingeniero componente a medida que evoluciona el modelo de diseño

Artefactos

4+1 Vistas

  • Índice

    • Enlaces a 4+1 vistas y modelo del dominio

    • Cardinalidad: 1
diagramaIndexUseCaseView

Vista Lógica

  • Índice

    • Enlaces a Diseño de Arquitectura, Casos de Uso, Clases y Paquetes

    • Cardinalidad: 1
diagramaVistaLogica

  • Diseño de la Arquitectura

    • Diagrama de Paquetes

    • Cardinalidad: 1..<paquetes>

height32

  • Diseño de Casos de Uso

    • Diagrama de Clases

    • Diagrama de Comunicación

    • Cardinalidad: 1..<casosUso>
diagramaDisenyoCasoUso
diagramaDisenyoCasoUsoSecuencia

  • Diseño de Clases

    • Diagrama de Clases con clases relacionadas, aferentes y eferentes

    • Cardinalidad: 1..<clases>
diagramaAnalisisClase

  • Diseño de Subsistemas

    • Diagrama de Paqutes, con subsitemas relacionados, aferentes y eferentes

    • Cardinalidad: 1..<subsistemas>
diagramaAnalisisPaquete

Vista de Implementación

  • Vista Implmentación

    • Componentes software deplegables en hardware y su trazabildad con los subsistemas de diseño

    • Cardinalidad: 1

height32

height32

Vista de Despliegue

  • Vista de Despliegue

    • Componentes hardware y su trazabilidad con los componentes software

    • Cardinalidad: 1

height32

height32

Síntesis

sintesis

Eres el jefe de proyecto de la aplicación:

  • ¿Por qué parte comenzarías, continuarías y terminarias la producción de código?

  • ¿Qué medidas aplicarías para obtener la calidad del software adecuada para facilitar la depuración de errores, la mantenibilidad corrective, perfective o adaptativa?

  • ¿Cómo repartirías las tareas de producción entre las personas del equipo de desarrollo?

  • Casos de Uso Priorizados y especificados,

  • Diseño de la Arquitectura

  • Diseño de Casos de Uso

  • Diseño de Clases, revisión

  • Diseño de Paquetes, revisión

  • Estimando cada actividad, entre 2 y 20 horas, y

  • Repartiendo cohesivamente entre el equipo de desarrollo

  • …​ con trazabilidad de todo!

Bibliografía

Obra, Autor y Edición Portada Obra, Autor y Edición Portada

  • Unified Software Development Process

    • Grady Booch, Ivar Jacobson y James Rumbaugh

    • Addison-Wesley; (1999)

height32

  • Rational Unified Process Made Easy, The: A Practitioner’s Guide to the RUP

    • Grady Booch, , Ivar Jacobson y James Rumbaugh

    • Addison-Wesley; (2003)

height32

  • Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development

    • Craig Larman

    • Pearson; (2004)

height32

  • Object Solutions. Managing the Object Oriented Project

    • Grady Booch

    • Benjamin Cummings; (1995)

height32

  • Object Oriented Analysis and Design with Applications

    • Grady Booch

    • Addison-Wesley; (2011)

height32

  • The Unified Modeling Language User Guide

    • Grady Booch

    • Pearson; (2005)

height32

  • UML Distilled. A Brief Guide to the Standard Object Modeling Language

    • Martin Fowler,Kendall Scott

    • Addison-Wesley; (2003)

height32

Ponente

  • Luis Fernández Muñoz

setillo

  • Doctor en Inteligencia Artificial por la UPM

  • Ingeniero en Informática por la UMA

  • Diplomado en Informática por la UPM

  • Profesor Titular de ETSISI de la UPM