LA NATURALEZA DE LAS RELACIONES ES AHORA ESPECÍFICA.
Enviado por Ariel Santos • 6 de Septiembre de 2016 • Resumen • 2.355 Palabras (10 Páginas) • 193 Visitas
Continuación 7.1.1
El modelo del contexto puede representarse mediante asociaciones, estas muestran simplemente que existen algunas relaciones entre las entidades que intervienen en la asociación.
LA NATURALEZA DE LAS RELACIONES ES AHORA ESPECÍFICA.
Es posible documentar el entorno del sistema con un simple diagrama de bloques, que manifieste las entidades en el sistema y sus asociaciones.
Al modelar las interacciones de un sistema con su entorno, se debe usar un enfoque abstracto que no contenga muchos detalles.
Cada uno de los casos de uso tiene que describirse en lenguaje natural estructurado
7.1.2 DISEÑO ARQIUTECTONICO
Después de definir las interacciones entre el sistema de software y el entorno del sistema, se aplica el diseño arquitectónico.
Para poder crear un diseño arquitectónico es necesario
- Identificar los principales componentes que constituyen al sistema y sus interacciones
- Organizar los componentes utilizando un patrón arquitectónico como un modelo en capas o cliente- servidor.
Cada subsistema escucha los mensajes en esa infraestructura y capta los mensajes que se dirigen a el
El BENEFICIO de esta arquitectura consiste en soportar diferentes configuraciones de subsistemas debido a que el emisor del mensaje no necesita dirigir el mensaje a un subsistema específico.
7.1.3 IDENTIFICACION DE CLASE DE OBJETO
La descripción de caso de uso ayuda a identificar objetos y operaciones del sistema.
Propuestas para identificar las clases de objetos en los sistemas orientados a objetos:
- Usar un análisis gramatical de una descripción en lenguaje natural del sistema a construir( objetos y atributos son sustantivos; Operaciones o servicios verbos)
- Usar entidades tangibles (cosas) en el dominio de aplicación, roles, eventos, interacciones, ubicaciones, unidades organizacionales, etc.
- Emplear un análisis basado en escenarios, donde a la vez se identifiquen y analicen varios escenarios de uso de sistema.
Las clases como los atributos y las operaciones pueden ser un punto de inicio para el diseño.
El conocimiento del dominio de aplicación se usa para identificar otros objetos, atributos y servicios.
Se necesitan atributos y operaciones para reportar el comprobar el buen funcionamiento.
En esta etapa del diseño hay que enfocarse en los OBJETOS
7.1.4 MODELOS DE DISEÑO
LOS MODELOS DE DISEÑO O SISTEMA MUESTRAN LOS OBJETOS O CLASES DE OBJETOS EN UN SISTEMA, INDICAN LAS ASOCIACIONE SY RELACIONES ENTRE TALES ENTIDADES.
Los modelos de diseño deben incluir suficiente detalle para que los programadores tomen decisiones de implementación.
Cuando los vínculos entre especificadores, diseñadores y programadores del sistema son indirectos es probable que se necesiten modelos más detallados.
Un paso importante en el proceso es determinar los modelos de diseño que se necesitaran y el nivel de detalle requerido en dichos modelos
El UML soporta hasta 13 diversos tipos de modelo pero rara vez se usan todos.
Minimizar el número de la producción de modelos reduce los costos del diseño y el tiempo requerido para completar el proceso de diseño.
Al usar UML para la elaboración de un diseño por lo regular desarrollara dos tipos de modelo de diseño
- MODELOS ESTRUCTURALES, describen estructura estática del sistema usando las clases de objetos y sus relaciones. Las relaciones importantes que pueden documentarse en esta etapa son relaciones de generalización, las relaciones usado por y las relaciones de composición.
- MODELOS DINAMICOS, explican la estructura dinámica del sistema y muestran las interacciones entre los objetos del sistema. Las interacciones que pueden documentarse incluyen la secuencia de peticiones de servicio realizadas por objetos, así como los cambios de estado que activan las interacciones de dichos objetos.
En las primeras fases del proceso de diseño, se considera que existen 3 modelos que son útiles para agregar detalle a los modelos de caso de uso y arquitectónico
- MODELOS DE SUBSISTEMA, exponen los agrupamientos lógicos de objetos en subsistemas coherentes. Representados mediante una forma de diagrama de clase en el que cada subsistema se muestra como un paquete de objetos encerrados. Estos modelos son ESTATICO UTIL (Estructurales)
- MODELOS DE SECUENCIA, ilustran la secuencia de interacciones de objetos. Se representan mediante una secuencia UML o diagrama de colaboración. MODELOS DIAMICOS
- MODELOS DE MAQUINA DE ESTADO, muestran como los objetos individuales cambian su estado en respuesta a eventos. Se representan en UML a través de diagramas de estado. MODELOS DIAMICOS.
Los diagramas de secuencia se usan para modelar el comportamiento cambiando de un grupo de objetos, también se desea resumir el comportamiento de un objeto o subsistema, en respuesta a mensajes y eventos para lograr esto se usa un modelo de los mensajes que recibe
El UML incluye diagramas de estado, inventados por Harel para descubrir modelos de máquina de estado.
Los diagramas de estado son modelos útiles de alto nivel de un sistema o la operación de un objeto; NO requiere un diagrama de estado para todos los objetos en el sistema muchos objetos son simples.
7.1.5 ESPECIFICACION DE INTERFAZ
Es necesario especificar las interfaces de modo que los objetos y subsistemas puedan diseñarse en paralelo.
El diseño de interfaz se preocupa por la especificación del detalle de la interfaz hacia un objeto o grupo de objetos, estas se pueden especificar en el UML con la misma notación de un diagrama de clase solamentre debe incluirse en la parte del nombre interface .
En un diseño de interfaz no se deben incluir detalles de la representación de datos pues los atributos no se definen en una especificación de interfaz
7.2 PATRONES DE DISEÑO
Se derivaron de ideas planteadas por Christopher Alexander, sugirió que había ciertos patrones comunes de diseño de construcción que eran relativamente agradables y efectivos.
EL PATRON es una descripción del problema y la esencia de su solución, de modo que la solución pueda reutilizarse en diferentes configuraciones.
EL PATRON NO ES UNA ESPECIFICACION DETALLADA, puede ser considerado como una descripción de sabiduría y experiencia acumulada.
...