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
diagramaCitas

¿Qué?

disenyoRAE

disenyosUML
Análisis Diseño

analizar los requisitos a través de su refinamiento y estructura para realizar una compresión más precisa de los requisitos, una descripción de los requisitos que es fácil de mantener y ayuda a estructurar el sistema:

desarrollar enfocados en los requisitos no funcionales y en el dominio de la solución para preparar para la implementación y pruebas del sistema:

  • Dar una especificación más precisa de los requisitos obtenidos en la captura de requisitos

  • Describir usando el lenguaje de los desarrolladores y poder introducir más formalismo y ser utilizado para razonar sobre el funcionamiento interno del sistema

  • Estructurar los requisitos de manera que facilite su comprensión, cambiándolos y, en general, mantenerlos

  • Acercase al diseño, aunque sea un modelo en sí mismo, y es por tanto un elemento esencial cuando el sistema está conformado en diseño e implementación

  • Adquirir una comprensión profunda sobre los aspectos de los requisitos no funcionales y limitaciones relacionadas con:

  • los lenguajes de programación,

  • la reutilización de componentes,

  • sistemas operativos,

  • tecnologías de distribución y concurrencia,

  • tecnologías de bases de datos,

  • tecnologías de interfaz de usuario,

  • tecnologías de gestión de transacciones,

  • y así sucesivamente

  • Diseño suficiente (JEDUF, Just Enough Design Upfront vs BDUF, Big Design Upfront)

    • Vista de Diseño/Lógica

  • Diseño sistemas

    • Vistas de Implementación/Desarrollo

    • Vista Física/Despligue

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

davidProyectoImplantacionDiseño

arbolMantenible
Objetivos

  • Capacitar para visualizar y razonar sobre el diseño utilizando una notación común

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

  • Crear una entrada apropiada como punto de partida para las disciplinas posteriores mediante la captura de los requisitos correspondientes a los distintos subsistemas, interfaces y clases

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

  • Capacitar para la descomposición del trabajo de implementación en piezas más manejables gestionados por diferentes equipos de desarrollo, posiblemente al mismo tiempo

  • Lenguaje Unificado de Desarrollo

  • Disciplina de Implementación, Pruebas y Despliegue

  • Disciplina de Gestión

¿Cómo?

Sencillez

Divide et impera (divide y vencerás)
— Máxima Latina
Julio César, Napoleón, Imperio Británico, ...
En igualdad de condiciones, la explicación más sencilla suele ser la correcta
— Navaja de Occam
Cualquier tonto inteligente puede hacer cosas más grandes y más complejas …​ se necesita un toque de genialidad y mucho coraje para moverse en la dirección opuesta"
— Einstein
A.
El descubrimiento de un orden no es tarea fácil. . . . sin embargo, una vez que el orden ha sido descubierto no hay dificultad alguna en reconocerlo
— Descartes

  • Circulo con 3 valores, abcisa, ordenada y radio, se definen infinitos puntos con máxima área para el mismo perímetro

  • Simetría, la explicación de una parte se reutiliza para la otra

  • Sistema de numeración binario con secuencias de 2 símbolos permite construir infinitos números

  • Proporciones, razones, relaciones, funciones, ecuaciones, …​: y=2^x, con 5 elementos defino infinitos puntos correspondientes a otro dado

  • Orden, criterio, …​: determina la localización de elementos en una posición precisa

Reusabilidad: disfrutando de la misma distancia, fórmula, manera, …​ para ahorrar esfuerzos

Cuando el grajo vuela bajo, hace un frio del carajo!!! …​

KISS

Antónimos Antonyms Libro Autor

Mantenlo sencillo, estúpido!

Keep it simple, stupid!

En un portaviones?!?

Kelly Jhonson

Mantenlo pequeño y sencillo!

Keep it short and simple

Mantenlo pequeño y simple!

Keep it small and simple

Comprender el algoritmo

Understand the Algorithm

Smell Code (Clean Code)

Robert Martin
Antónimos Antonyms Libro Autor

Código Espagueti

Spaghetti Code

Antipatrón de Desarrollo

William H. Brown et al

Generalidad Espculativa

Speculative Generality

Smell Code -(Refactoring)

Martin Fowler

Intenciones obscuras

Obscured Intent

Smell Code (Clean Code)

Robert Martin
Hay dos maneras de diseñar software: una es hacerlo tan simple que sea obvia su falta de deficiencias, y la otra es hacerlo tan complejo que no haya deficiencias obvias
— C.A.R. Hoare
1980 ACM Turing Award Lecture
“Sin embargo, no es suficiente para dejar las comillas alrededor de la palabra ‘funciona’. Usted debe saber que la solución es correcta. A menudo, la mejor manera de obtener este conocimiento y comprensión es refactorizar la función en algo que es tan limpio y expresivo que es obvio cómo funciona".
— Martin Fowler
La diferencia entre un programador inteligente y un programador profesional es que el profesional entiende que la claridad es el rey. Los profesionales utilizan su potencia para lo bueno y escribir código que otros puedan entender
— Martin Fowler
Cualquier tonto puede escribir código que entienda un ordenador. Sólo los buenos programadores escriben código que puedan entender los humanos
— Martin Fowler
Refactoring
- Violaciones

  • Nombres de métodos con extraños nombres abstractos deben ser renombrados para “traerlos a la tierra”

  • Métodos que no usan parámetros deberían ser eliminados

  • Si tienes clases abstractas que no están haciendo mucho, colapsa la jerarquía

  • Innecesaria delegación puede ser eliminadacon la clase “en línea”

  • Complejos algoritmos generalistas para situaciones muy concretas

  • Complejos algritmos muy eficientes cuando no hay necesidad

  • …​

  • Casa de herrero, cuchara de palo, organizamos sistemas de información de los clientes perfectamente estructurados con sistemas de información de software preñados de ciclos, repeticiones, lastres, ilegibles, …​ sin pruebas para probar cómo funciona si toco algo!!!

Código Limpio

Clean code
El código limpio es simple y directo. El código limpio se lee como una prosa bien escrita. El código limpio nunca oscurece la intención del diseñador, sino que está lleno de abstracciones nítidas y líneas directas de control
— Grady Booch
Rational Unified Process
Sabes que estás trabajando en un código limpio cuando cada rutina que lees resulta ser más o menos lo que esperabas. Puede llamarlo código hermoso cuando el código también hace que parezca que el lenguaje fue creado para el problema
— Ward Cunningham
Wiki
Duplicación reducida, alta expresividad y construcción temprana de abstracciones simples. Eso es lo que hace que el código sea limpio para mí
— Ron Jeffries
Extreme Programming Installed
Me gusta que mi código sea elegante y eficiente. La lógica debe ser sencilla para dificultar la ocultación de los errores, las dependencias mínimas para facilitar el mantenimiento, el manejo de errores completo de acuerdo con una estrategia articulada y el rendimiento cercano al óptimo para no tentar a las personas a ensuciar el código con optimizaciones sin principios. El código limpio hace una cosa bien
— Bjarne Stroustrup
The C++ Programming Language
El código limpio puede ser leído y mejorado por un desarrollador que no sea su autor original. Tiene pruebas unitarias y de aceptación. Tiene nombres significativos. Proporciona una forma en lugar de muchas formas de hacer una sola cosa. Tiene dependencias mínimas, que se definen explícitamente, y proporciona una API clara y mínima
— Dave Thomas
Eclipse
Podría enumerar todas las cualidades que noto en un código limpio, pero hay una cualidad general que conduce a todas ellas. El código limpio siempre parece haber sido escrito por alguien a quien le importa. No hay nada obvio que puedas hacer para mejorarlo. El autor del código pensó en todas esas cosas, y si intentas imaginar mejoras, volverás a donde estás, sentándote apreciando el código que alguien te dejó, código dejado por alguien que se preocupa profundamente por el artesanía
— Michael Feathers
Working Effectively with Legacy Code

Itinerario

Temas Contenidos Nivel
diagramaDisenyo

  • Arquitecturas MVC: Modelo/Vista/Controlador (MVP, MVVM, …​), Data Access Object, Arquitecturas Ágiles: Hexagonal Architecture , Clean Architecture, Onion Architecture

  • Arquitectura del Software: actores, documentación 4+1 vistas, principios de cohesión y acoplamiento de paquetes

Paquetes

  • Patrones de Diseño: creacionales, estructurales, de comportamiento, Object Value, …​

Prácticas recurrentes

  • Diseño Orientado a Objetos: Principios Open/Close, Sustitución de Liskov, Patrón Método Plantilla, Inversión de Dependencias, Inversión de Control, Inyección de Dependencias, …​

Jerarquías de Clasificación

  • Diseño Modular: Cohesión, Acoplamiento, Granularidad, …​, Smell Code, …​, Modelo, Vista, Controlador, …​

Clase y Método

  • Diseño: Modelo del Dominio, Gestión de Dependencias, DRY, YAGNI, nombrado, comentarios, …​

Línea

Sintesis

sintesis

Bibliografía

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

  • The Unified Modeling Language User Guide

    • Booch, Jacobson, Rumbaugh

    • Pearson Education, 2005

height32

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

    • Fowler, Scott

    • Addison-Wesley, 2003

height32

  • Object Oriented Analysis and Design with Applications

    • Grady Booch

    • Addison-Wesley; (2011)

height32

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

    • Larman Craig

    • Prentice Hall; (2004)

height32

  • Object-Oriented Software Construction

    • Bertrand Meyer

    • Prentice Hall; (1997)

height32

  • Eiffel : The Language (PRENTICE HALL OBJECT-ORIENTED SERIES)

    • Bertrand Meyer

    • Prentice Hall; (1991)

height32

  • Code Complete

    • Steve McConnell

    • Microsoft Press; (2004)

height32

  • Clean Code. A Handbook of Agile Software Craftsmanship

    • Robert C. Martin

    • Prentice Hall; (2008)

height32

  • An Introduction to Object-Oriented Programming

    • Timothy A. Budd

    • Addison-Wesley; (2001)

height32

  • Agile Software Development, Principles, Patterns and Practices

    • Robert-C Martin

    • Pearson; (2006)

height32

  • The Mythical Man Month. Essays on Software Engineering

    • Frederick P. Brooks

    • Prentice Hall; (1995)

height32

  • Object Solutions. Managing the Object Oriented Project

    • Grady Booch

    • Addison-Wesley; (1789)

height32

  • Patrones de diseño

    • Erich Gamma et al

    • Anaya (2002)

height32

  • AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis

    • William J. Brown

    • John Wiley & Sons (1998)

height32

  • Patterns of Enterprise Application Architecture

    • Martin Fowler

    • Addison-Wesley; (2002)

PatternsOfEnterpriseApplicationArchitecture

  • Clean Architecture: A Craftsman’s Guide to Software Structure and Design

    • Robert C Martin

    • Prentice Hall; (2017)

CleanArchitecture

  • The Art of Software Architecture: Design Methods and Techniques

    • Stephen T. Albin

    • Wiley; (2003)

TheArtOfSoftwareArchitecture

  • Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

    • Nick Rozanski, Eóin Woods

    • Addison-Wesley; (2011)

SoftwareSystemsArchitecture

  • Software Architecture in Practice

    • Len Bass, Paul Clements, Rick Kazman

    • Addison-Wesley; (2012)

SoftwareArchitectureInPractice

  • Pattern-oriented Software Architecture: A System of Patterns

    • Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad

    • Wiley (1996)

PatternOrientedSoftwareArchitecture

  • Documenting Software Architectures

    • Paul Clements, Felix Bachmann, Len Bass ..

    • (2001)

DocumentingSoftwareArchitectures

  • Integrating Software Architecture-Centric Methods into Extreme Programming

    • Robert L. Nord, James E. Tomayko, Rob Wojcik

    • (2004)

IntegratingSoftwareArchitectureCentricMethods

  • Refactoring. Improving the Design of Existing Code

    • Martin Fowler,Kent Beck,John Brant,William Opdyke,Don Roberts

    • Addison Wesley; (1999)

height32

  • Extreme Programming Explained. Embrace Change. Embracing Change

    • Kent Beck,Cynthia Andres

    • Addison-Wesley; (2004)

height32

  • C++ Programming Language

    • Stroustrup Bjarne

    • Addison Wesley; (2013)

height32

  • The Clean Coder: A Code of Conduct for Professional Programmers

    • Robert C. Martin

    • Addison-Wesley; (2011)

height32

  • Desarrollo ágil esencial: Vuelta a las raíces

    • Robert C. Martin

    • Anaya; (2020)

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