04 de marzo - JoseA4718/Portafolio-I-2020 GitHub Wiki
Se entregó el quiz#1
Diagrama de Clases
Asociación y Composición:
La agregación y composición son ejemplos de relaciones entre clases, la agregación es débil y la composición es fuerte. Un ejemplo de agregación es un niño y una escuela, mientras que un ejemplo de composición es la tierra con las plantas. Entidad empleado-Entidad empresa; un empleado puede trabajar en mas de una compañía, si la empresa se va del país el empleado puede seguir trabajando en otra empresa. La relación cuarto-casa, por otro lado es fuerte (composición) pues si se rompe la casa se rompe el cuarto.
Las flechas deben apuntar a la clase padre en caso de herencia.
Realización
Es una relación de mutua necesidad, son clases que dependen de otra clase, pero esa clase no puede hacer nada porque lo necesario para servir lo tienen las clases secundarias.
Dónde se Pueden Crear Diagramas de Clase?
Hay varios programas para hacerlos.
Forward Engineering: se crea el código desde el diagrama.
Reverse Engineering: Generar diagramas desde un código existente.
Ejemplos:
- Miscrosoft Visio
- Lucid Chart
- IBM Rational Software Architect
- DIA
Diseño Orientado a Objetos:
Existe mas de una manera de hacer cosas, pero como podría calificar un buen diseño? Depende de quien está buscando la solución al problema. Pero existen principios para acercarse a ese atributo de buen diseño. Si los sigo debería de darme un sentimiento de tranquilidad y seguridad de que lo que estoy haciendo esta bien.
El diseño se empieza en el momento en que le dan "green light" (asociado al presupuesto del proyecto para empezar a trabajar).
SCRUM se usa para organización de proyectos.
Antes de modelar se debe entender el problema y crear un modelo conceptual general. Este modelo no debe ser muy elaborado, simplemente debe hacerlo entender el problema al que se está enfrentando.
Fase de Análisis
Hacer una investigación a profundidad para entender lo que se necesita hacer. La mayoría del tiempo no está claro lo que el cliente quiere, para eso se habla con el cliente y se discute que es lo que se quiere a profundidad. Para esto se pueden usar historias de usuario
Historias de Usuario
Son una manera simple de recolectar requerimientos, por ejemplo, como usuario quiero subir fotos para publicarlas; pero como administrador quiero aprobar fotos antes de que sean posteadas para asegurarme de que son apropiadas.
Otra herramienta importante para entender el problema es usado prototipos; prototipos son una versión básica dela solución que queremos construir. El objetivo principal es mostrarle a los usuarios como la versión final se podría ver.
Fase de Diseño:
Es el paso final del odd. Con todo lo recibido anteriormente ahora sí se puede empezar a crear su diseño. El output de esta fase es el diagrama de clases.
Paso 1: poner mucha atención a las historias de usuario, no piense que todo va a salir de una y al primer intento, pues en software hay un desarrollo iterativo, con mejoras exponenciales. Se pueden encontrar clases que al final ni se van a usar. El producto final se puede ver muy diferente al primer diseño.
Paso 2: Identificar todas las asociaciones que existan entre las diferentes clases, lo que puede resultar en remover o añadir clases que se ocupen conforme se avanza en el proceso. LAS CLASES SE DEBEN RELACIONAR CON AL MENOS OTRA CLASE. SI NO SE USA PARA NADA ES UN CERO.
Paso 3: Identificar los atributos y métodos, añadir los atributos y métodos para cada clase, intente pensar en un punto de vista general de cómo cada clase cumplirá su rol.
PATRONES DE DISEÑO
Es una regularidad discernible en el mundo real o un diseño hecho a mano. Uno de los principios que usan los expertos es que no todos los problemas se resuelven desde cero. Ya hay librerías que puedo utilizar (no invente la rueda). Los diseñadores expertos usan soluciones que les sirvieron en el pasado para ahorrar tiempo. Se pueden tomar parte de las soluciones para ahora resolver parte de otro problema. Son una solución general re utilizable a un problema común en un contexto de diseño de software. Un patrón contiene una descripción de como se comunican unos objetos que son personalizados para encontrar un diseño general en un contexto particular. Estos patrones ya han sido probadas por personas expertas en software.
El primer catalogo de patrones de diseño fue hecho en 1994 por:
- Erich Gamma
- Richard Helm
- Ralph Johnson
- John Vlissides
Recopilaron las mejores practicas en cuanto a diseño de software, conocidas informalmente por muchos ingenieros. También propusieron patrones nuevos hechos por ellos. A día de hoy es referencia para el estudio de patrones de diseño.
Los patrones se puede clasificar en propósito y alcance, el propósito refleja lo que el patrón hace, mientras que el alcance especifica si el patrón aplica para clases u objetos.
Propósito:
- Creacional: le concierne el proceso de crear los objetos
- Estructural: lidian con aspectos de composición entre clases u objetos
- De comportamiento: define la forma en el que clases u objetos se pueden distribuir responsabilidades.
Alcance:
- Clases
- Objetos