Diseño del sistema INTEGRANTES PEDRO ARTURO RINCON

Presentación del tema: "Diseño del sistema INTEGRANTES PEDRO ARTURO RINCON"— Transcripción de la presentación:

1 Diseño del sistema INTEGRANTES PEDRO ARTURO RINCON
DIANA MARCELA GRANADOS INGENIERIA DEL SOFTWARE

2 DISEÑO DEL SISTEMA DEFINICION:
transformación del modelo de análisis en un modelo de diseño el modelo de análisis describe el sistema completo desde el punto de vista de los actores y sirve como base de comunicación entre el cliente y los desarrolladores. El modelo de análisis, Sin embargo, no contiene información sobre la estructura interna del sistema, configuración hardware , o como el sistema debe ser realizado. ESTRATEGIAS CONSTRUCCION DEL SISTEMA: Definir los objetivos del diseño en cuanto al proyecto. Partir el sistema en subsistemas o partes manejables de tal manera que puedan ser ejecutados por equipos individuales.(para hacer frente a la complejidad).

3 DISEÑO DEL SISTEMA Plataforma de hardware / software en el que el sistema funcione. Gestión de datos. la funcionalidad del sistema se refiere a la creación o la manipulación de datos persistentes. Por ello el acceso a los datos debe ser rápido y fiable. Si la recuperación de datos es lenta, todo el sistema será lento. Control flujo: como funcionan las operaciones de secuencia del sistema . Puede este manejar mas de una interacción en un tiempo determinado. control de acceso : El control de acceso debe ser coherente en todo el sistema especificar quién puede y quién no puede acceder a ciertos datos debe ser el mismo en todos los subsistemas.

4 DISEÑO PLAN CASA RESIDENCIAL
1.Establecer dialogo con el cliente (n° habitaciones, tamaño, tipo piso) 2.Diseño de plano de casa por arquitecto.(ubicación de paredes puertas ventanas) de acuerdo a una serie de requisitos funcionales: Cocina cerca comedor y el garaje Baño cerca de los dormitorios 3.El arquitecto puede depender de una serie de normas para establecer las dimensiones de cada habitación y la ubicación de la puerta: Muebles de cocina vienen en tamaños fijos incrementos y camas vienen en tamaños estándar 4.Las decisiones deben ser de acuerdo a las especificaciones del cliente.

5 Ejemplo plano casa Se muestra tres versiones de una plano de una casa residencial. Se debe satisfacer las siguientes restricciones: 1.Esta casa debe tener dos dormitorios, un estudio, una cocina y una sala de estar. 2. La distancia total de recorrido debe reducirse al mínimo. 3. El uso de la luz del día debe ser superior

6 Ejemplo plan de planta VERSIÓN INICIAL :
Comedor lejos de la cocina para solucionar este problema lo cambiamos con dormitorio2. .

7 SEGUNDA VERSION : La cocina y las escaleras están muy lejos de la Puerta de entrada. Para solucionar este problema, pasamos la puerta de entrada a la pared norte. Esto permite reorganizar 2 dormitorios y mover el baño más cercano a las dos habitaciones

8 TERCERA VERSIÓN : cumple las restricciones. Una vez completado el diseño de la planta se pone a disposición de cada habitación individual. Los planes para tuberías, líneas eléctricas, y conductos de calefacción que se proceda.

9 EL DISEÑO DE UNA PLANTA EN LA ARQUITECTURA ES SIMILAR AL DISEÑO DE SISTEMA DE INGENIERÍA DE SOFTWARE PORQUE: El conjunto se divide en componentes más simples es decir: habitaciones, subsistemas) y interfaces (puertas, servicios) Requisitos Funcional(número de dormitorios, los casos de uso ) No funcional:( sala de estar, tiempo de respuesta) Diseño de sistema impacta la implementación de actividades (es decir, el diseño de la cocina, la complejidad de la codificación de subsistemas individuales) los resultados de repetir el trabajo es costoso si se ha de cambiar después (es decir, mover muros, cambiar las interfaces del subsistema).

10 ANALISIS RESULTADO EN EL MODELO DE REQUERIMIENTOS DESCRITO POR LOS SIGUIENTES PRODUCTOS
un conjunto de requisitos no funcionales Restricciones tales como : tiempo máximo de respuesta, rendimiento mínimo, fiabilidad, la plataforma de sistema Operativo. un modelo de casos de uso, que describe la funcionalidad del sistema desde el punto de vista de los actores . un modelo de objetos, que describe las entidades manipuladas por el sistema Un diagrama de secuencia para cada caso de uso, que muestra la secuencia de interacciones entre los objetos que participan en el caso de uso

11 SUBSISTEMAS Y CLASES Para reducir la complejidad del dominio de aplicación, se identificaron partes más pequeñas llamadas clases y se organizaron en paquetes. De forma similar, para disminuir la complejidad del dominio de solución, se descompone el sistema en partes más simples, llamadas subsistemas, la cuales están hechas de un número de clases de dominio de solución En el caso de subsistemas complejos, recursivamente aplicamos este principio y descomponemos un subsistema en subsistemas más simples.

12 SISTEMA MANEJO DE ACCIDENTES
Un subsistema DispatcherInterface, implementando la interfaz de usuario para el Dispatcher (despachador). Un subsistema FieldOfficerInterface, (oficial de campo). Un subsistema IncidentManagement, implementando la creación, modificación y almacenaje de incidentes. Un subsistema Notificación, implementando la comunicación entre las terminales FieldOficcer (oficial de campo) y las estaciones Dispatcher (Despachador).

13 SERVICIOS E INTERFACES DE SUBSISTEMA
Un subsistema se caracteriza por los servicios(conjunto de operaciones relacionadas que comparten un propósito común.) y provee a los otros subsistemas. Un subsistema para proveer servicios de notificación : define operaciones para enviar anuncios, busca canales de notificación, y se subscribe o abandona un canal. El conjunto de operaciones de un subsistema que están disponibles para otros subsistemas forman la interface de subsistema. La interface del subsistema, también es conocida como la interface de aplicación del programador (API: Aplicación Programmer Interface), incluye el nombre de las operaciones, sus parámetros, y sus comportamientos de alto nivel La definición de un subsistema en términos de los servicios que provee nos ayuda : a enfocarnos en su interface en lugar de su implementación Una buena interface de subsistema provee poca información sobre su implementación. minimizar el impacto de los cambios cuando revisamos la implementación de un subsistema.

14 ACOPLAMIENTO Una propiedad deseable de la descomposición de un subsistema es que los subsistemas estén tan poco acoplados como sea posible. Esto minimiza el impacto de errores o futuros cambios que tengan en la correcta operación del sistema. Considere, por ejemplo, un compilador en el cual un árbol de análisis es producido por el subsistema de análisis de sintaxis y enviado al subsistema de análisis semántico. Ambos subsistemas acceden y modifican el árbol de análisis. Una forma eficiente de compartir grandes cantidades de datos es permitir a ambos subsistemas acceder a los nodos del árbol mediante los atributos. Esto introduce, sin embargo, un acoplamiento apretado: Ambos subsistemas necesitan saber la estructura exacta del árbol de análisis y sus invariancias.

15 ARBOL DE ANALISIS

16 ARBOL DE ANALISIS

17 COHERENCIA Fuerza de las dependencias dentro de un subsistema. Si un subsistema posee muchos elementos que están relacionados los unos a los otros y realizan tareas similares, su coherencia es alta. Si un subsistema posee una cantidad de objetos no relacionados, su coherencia es baja. Una propiedad deseable en un subsistema es aquella que genera sistemas con alta coherencia. Ejemplo considere un sistema de seguimiento de decisiones para grabar problemas de diseño, discusiones, evaluaciones alternativas, decisiones y su implementación en términos de tareas:

18 Problema de diseño (DesignProblem) y alternativa (Alternative) representan la exploración del espacio de diseño. criterio (Criterion) representa las cualidades en las cuales estamos interesados Una vez que hemos juzgado la alternativa (Alternative) explorada contra los criterios (Criterio), tomamos una decisión (Decision) y la implementamos en términos de tareas (Task). descompuestas en subtareas (SubTask) ActionItem.(tareas mas pequeñas) El sistema de seguimiento de decisiones :es suficientemente pequeño de modo que podríamos englobar todas esas clases en un subsistema llamado DecisionSubsystem la clase modelo puede ser particionada en dos subgrafos

19 SUBGRAFOS (RATIONALSUBSYSTE)

20 CAPAS Y PARTICIONES El objetivo del diseño del sistema es manejar la complejidad mediante la división del sistema en piezas más pequeñas y manejables. Esta aplicación sistemática lleva a una descomposición jerárquica en la cual, cada sistema o capa provee servicios de mayor nivel, usando servicios provistos por subsistemas de mas bajo nivel.

21 ARQUITECTURA CERRADA (MODELO OSI)

22 CAJA DE HERRAMIENTAS DE LA INTERFAZ DE USUARIO MOTIF PARA X11.
ARQUITECTURA ABIERTA CAJA DE HERRAMIENTAS DE LA INTERFAZ DE USUARIO MOTIF PARA X11.

23 ARQUITECTURA DE SOFTWARE
A medida que la complejidad de un sistema se incrementa, la especificación de la descomposición de un sistema es crítica. Es difícil modificar o corregir una descomposición débil una vez que el desarrollo ha comenzado, ya que la mayoría de las interfaces de los subsistemas tienen que cambiar. En reconocimiento a la importancia de este problema, el concepto de arquitectura de software ha emergido. Una arquitectura de software incluye el sistema de descomposición, el control de flujo global, políticas de manejo de errores y protocolos de comunicación entre subsistemas.

24 ARQUITECTURA DE REPOSITORIO
En esta los subsistemas acceden y modifican datos de una estructura de datos individual llamada repositorio central. Los subsistemas son relativamente independientes e interactúan únicamente mediante la estructura de datos central. El control de flujo puede ser dictado por el repositorio central o por los subsistemas. La arquitectura de repositorio es típica para sistemas de administración de bases de datos (como el sistema de un banco, modernos compiladores, etc.). La ubicación central de los datos facilita lidiar con la concurrencia y los problemas de integridad entre los subsistemas.

25 REPOSITORIO (USO CONTROL FLUJO)
Las arquitecturas de repositorio son adecuadas para aplicaciones con tareas complejas de procesamiento de datos que cambien constantemente. La principal desventaja de los sistemas de repositorio, es que rápidamente el repositorio central puede volverse un cuello de botella, tanto en rendimiento como en modificabilidad.

26 MODELO/VISTA/CONTROLADOR (MVC)
En esta arquitectura los subsistemas están clasificados en 3 tipos: Los modelos de subsistemas que mantienen el dominio de conocimiento las vistas de subsistemas que se encargan de mostrárselo al usuario controlador de subsistemas que manejan la secuencia de interacciones con el usuario. El MVC es un caso particular de arquitectura de repositorio, donde un modelo implementa la estructura central de datos y el control de objetos que dicta el control de flujo. Una ventaja de la arquitectura MVC es que cuando se presenta algún cambio en la información contenida en el modelo, su vista se actualiza mostrando los nuevos cambios

27 ARQUITECTURA CLIENTE/SERVIDOR
En este, un subsistema, el servidor, provee servicios a instancias de otros subsistemas llamadas clientes, los cuales son responsables de interactuar con el usuario. La solicitud de un servicio se hace mediante un proceso remoto de llamada o mediante un agente de objetos. El control de flujo entre los clientes y el servidor es independiente, excepto por la sincronización para manejar solicitudes o recibir resultados.

28 Un ejemplo de arquitectura cliente/servidor podría ser un sistema de información con una base de datos central. Los clientes son responsables de recibir entradas (inputs) por parte del usuario, realizando algunos controles y realizando transacciones con la base de datos una vez que tiene todos los datos. El servidor es responsable de realizar la transacción y mantener la integridad de los datos. En este caso, la arquitectura cliente/servidor es un caso especial de arquitectura de repositorio, donde la estructura central de datos es manejada por un proceso. De cualquier modo, los sistemas cliente/servidor no están restringidos a un solo servidor, como ocurre en internet, donde un cliente puede acceder a datos en miles de servidores. La arquitectura cliente/servidor es adecuada para sistemas distribuidos que manejan grandes cantidades de datos.

29 ARQUITECTURA PEER-TO-PEER
Esta es una generalización de la arquitectura cliente/servidor en la cual los subsistemas pueden actuar tanto como cliente o como servidores, en el sentido en que cada subsistema puede solicitar y proveer servicios. El control de flujo dentro de cada subsistema es independiente excepto para la sincronización de solicitudes Un ejemplo de arquitectura peer-to-peer es una base de datos que, por un lado, acepta solicitudes de la aplicación, y por otro, envía notificaciones a la aplicación cada vez que ciertos datos cambian. Los sistemas peer-to-peer son más difíciles de diseñar que los cliente/servidor. Introducen la posibilidad de bloqueos y complicados flujos de control.

30 ARQUITECTURA DE TUBERÍAS Y FILTROS
los subsistemas procesan datos recibidos de un conjunto de entradas y envían resultados a otros subsistemas en un conjunto de salidas. Los subsistemas son llamados filtros, y las asociaciones entre los subsistemas son llamadas tuberías. Cada filtro solo conoce el contenido y el formato de los datos recibidos en las tuberías de entrada, no los filtros que los producen. Cada filtro se ejecuta concurrentemente y la sincronización es hecha a través de las tuberías. Esta arquitectura es modificable: los filtros pueden ser sustituidos o modificados para conseguir otros propósitos. La arquitectura de tuberías y filtros es adecuada para sistemas que aplican transformaciones a tramas de datos sin intervención de usuarios. No son adecuados para sistemas que requieren interacciones más complejas entre los componentes, tales como un sistema de manejo de información o un sistema interactivo.

31 DIAGRAMAS DE IMPLEMENTACION EN UML
Son usados para representar la relación entre los componentes en tiempo de ejecución y los nodos hardware. Los componentes son entidades auto-contenidas que proveen servicios a otros componentes o actores. Un servidor web, es un componente que provee servicios a navegadores web. Un sistema distribuido puede estar compuesto de varios componentes en tiempo de ejecución interactuando entre sí.

32 PREGUNTAS

33 GRACIAS