DIAGRAMA DE CLASES
Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en el sistema, y los componentes que se encargaran del funcionamiento y la relación entre uno y otro.
    • Propiedades también llamados atributos o características, son valores que corresponden a un objeto, como color, material, cantidad, ubicación. Generalmente se conoce como la información detallada del objeto. Suponiendo que el objeto es una puerta, sus propiedades serían: la marca, tamaño, color y peso.
    • Operaciones son aquellas actividades o verbos que se pueden realizar para este objeto, por ejemplo abrir, cerrar, buscar, cancelar, acreditar, cargar. De la misma manera que el nombre de un atributo, el nombre de una operación se escribe con minúsculas si consta de una sola palabra. Si el nombre contiene más de una palabra, cada palabra será unida a la anterior y comenzará con una letra mayúscula, a excepción de la primera palabra que comenzará en minúscula. ejemplo: abrirPuerta, cerrarPuerta, buscarPuerta, etc.
    • Interfaz es un conjunto de operaciones y o que permiten a un objeto comportarse de cierta manera, por lo que define los requerimientos mínimos del objeto.
    • Herencia se define como la reutilización de un objeto padre ya definido para poder extender la funcionalidad en un objeto hijo. Los objetos hijos heredan todas las operaciones y o propiedades de un objeto padre. ejemplo: Una persona puede subdividirse en Proveedores, Acreedores, Clientes, Accionistas, Empleados; todos comparten datos básicos como una persona, pero además tendrá información adicional que depende del tipo de persona, como saldo del cliente, total de inversión del accionista, salario...

bunas en esta secion le hablare un poco de el diseño del software.
En esta etapa del desarrollo se llevan a cabo algunos bosquejos, o diagramas que permiten comprender la magnitud del software y facilitan al desarrollador estructurar de su trabajo. Es común referirse a estos diagramas como los planos del software, haciendo analogía con la arquitectura.
La finalidad del diseño es tener una idea, al menos visual, y genérica de todo el sistema. Un buen análisis de requisitos, restricciomes, y otros factores que uno considere oportuno considerar puede llevar a un diseño bastante maduro y aproximado de como concebir al software.
Esto puede ser de mucha utilidad. Por ejemplo, nos sirve para determinar aquellos puntos sencibles o débiles. Esto puede indicarnos que allí hay que poner atención y analizar objetivamente. Por tanto, podríamos reestructurar todas las actividades teniendo en cuenta las necesidades y o el impacto del riesgo.

HERRAMIENTAS TIC

GLIFFY

YUML

CREATELY

son herramientas muy útiles para elaborar nuestros casos de usos al principio son  un poco complicadas pero cuando empiezas a utilizarla ya se nos hacen mas fáciles. 

REQUISITOS

estos son necesidad documentada sobre el contenido, forma o funcionalidad de un producto o servicio.

estos son

Necesario: Lo que pida un requisito debe ser necesario para el producto.

Conciso: Debe redactarse en un lenguaje comprensible por los inversores en lugar de uno de tipo técnico y especializado, aunque aun así debe referenciar los aspectos importantes.

Consistente: No deben entrar en conflicto con otro requisito diferente, ni con parte de otro. Asimismo, el lenguaje empleado entre los distintos requisitos debe ser consistente.

Completo: Deben contener en sí mismos toda la información necesaria, y no remitir a otras fuentes externas que los expliquen con más detalle.

Alcanzable: Un requisito debe ser un objetivo realista, posible de ser alcanzado con el dinero, el tiempo y los recursos disponibles.

Verificable: Se debe poder verificar con absoluta certeza, si el requisito fue satisfecho o no. Esta verificación puede lograrse mediante inspección, análisis, demostración o testeo.

REQUERIMIENTOS

Es una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. 

Necesario: Es necesario si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso.

 

Conciso: Un requerimiento es conciso, si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro. 

Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión. 

Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento. 

UML

en esta semana hablamos un poco de lo que es UML, un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema, este ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio o funciones del sistema.

DIAGRAMA DE CASO DE USO

El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactuan (operaciones o casos de uso).

Donde los muñecos son los actores y los círculos las operaciones.

SEMANA DE PARCIALES
una semana muy larga para algunos y muy corta para otras, una semana en donde se puso apenas nuestros conocimientos, una semana que nos sirvió para afianzar nuestros conocimientos a reforzar nuestras dudas las cuales eran mucho pero que se logro salir adelante, esto fue muy provechoso, nos obliga a leer y estudiar un poco mas.