Práctica de Tacticas y Viewtypes (Ingeniería II)

Bibliografía recomendada: Libro “Software Architecture in Practice” (Bass, Clements, Kazman), capítulo 5.

Tacticas

1. Tac - tic - tac - tic - …

1. ¿Qué tácticas conoce para los atributos de calidad disponibilidad, modificabilidad, performance, seguridad, testeabilidad, usabilidad?

2. ¿Cuál es la relación entre los siguientes conceptos: atributo de calidad, escenario, táctica, diseño, arquitecto, arquitectura y viewtype?

1.

Tacticas

	Tacticas	Resumen Tacticas
Disponibilidad	Deteccion de falla: Ping / Echo, HeartBeat, Excepciones Recuperación de la falla: Preparación y reparación (votacion, redundancia activa y pasiva). Reintroducción (Checkpoint/Rollback) Prevención de fallas: Retirar del servicio, Transacciones.	Todas las tacticas involucran algun tipo de redundancia, monitoreo para detectar un failure, y recovery cuando un failure es detectado .
Modificabilidad		El objetivo es controlar el tiempo y costo al implementar, testear y deploy cambios
Performance	Consumo de recursos: Eficiencia computacional, overhead. Administración de recursos: concurrencia, aumentar recursos, caching. Resource arbitration: Politicas de scheduling	El goal es generar una respuesta a un evento que llega al sistema dentro de una restriccionde tiempo
Seguridad	Resistir ataques: Autenticar y autorizar usuarios. Confidencialidad e integridad de datos. Limitar exposicion. Detectar ataques: Deteccion de intrusos. Recuperacion de un ataque: Restore	En general se trata de resistir/detectar/recover from ataques,
Testeabilidad		Permitir facil testeo
Usabilidad	Tiempo de diseño: Separar interfaz del resto del sistema. “reglas de oro de la usabilidad”: Diálogos simples y naturales, Ser consistente, Proveer atajos, Dar buenos mensajes de error, Ayuda y documentación.	En general, dar soporte al usuario durane la ejecucion, y tratar los problemas iterativamente en la interfaz de usuario en tiempo de diseño

2.

Las tacticas son usadas por el arquitecto para crear un view type (vista de arquitectura orientada a las estructuras modulos, C&C-Componentes y Conectores, allocation/asignation) que es parte de la arquitectura. Las tacticas definen deciciones de diseño que controlan un QA quees especificado en un escenario.

2. Disponibilidad

Dado un sistema cuya arquitectura consiste en un pool de procesos que reciben un catálogo de mensajes, se caracteriza el siguiente escenario de disponibilidad:

• Fuente: Externo al sistema
• Estímulo: Mensaje no anticipado
• Artefacto: Proceso
• Ambiente: Operación Normal
• Respuesta: Reporta al operador "continuar"
• Medida: No hay caida

• a) ¿Qué inconvenientes encuentra en controlar el atributo con la táctica de Ping/echo?
• b) Proponga una táctica de disponibilidad para controlar este atributo de calidad.

a) Es una tactica de deteccion de fallas, si bien la falla es detectada no se satisface la medida de la respuesta que es que no haya caidas. Como se trata de un pool de procesos no se sabe a cual mandar el ping.

b) Tal vez process monitor sirva por ser una tactica de prevención de fallas que trabaja con procesos (<- ¿Esto no es lo mismo que Heartbeat? Mejor usar ese término).

3. Modificabilidad

Dado el siguiente diagrama de vista de módulos: (ver imagen)

• 1. Modifique la arquitectura planteada aplicando las tácticas de modificabilidad que crea necesarias.
• 2. Sobre el nuevo diseño verifique las medidas de respuestas sobre los siguientes escenarios:
  • a. Se necesita agregar un atributo monto_sueldo a todas las entidades del módulo de RRHH
  • b. Se necesita reemplazar el módulo de Sueldos
  • c. Se necesita que un usuario contable cambie los porcentajes de los Impuestos a aplicar.

4. Seguridad

Dado el siguiente diagrama de la vista de Deploy de un sistema web: (ver imagen)

• a) ¿Qué tácticas de seguridad se emplearon en esta arquitectura?
• b) ¿Qué tácticas de seguridad considera que pueden agregarse? ¿Cómo las documentaría?
• c) Si tuviera un escenario en el que debería testear la integridad del sistema, ¿Qué tácticas de testing aplicaría? ¿Cómo las documentaría?

5. Usabilidad

La usabilidad no siempre es considerada durante el diseño de la arquitectura de una solución. Esto dificulta alcanzar los objetivos de la misma ya que es menospreciada. Piense en un sistema cuya arquitectura conozca e intente enumerar las tácticas de usabilidad empleadas.

6. Casinopolis

Tomando como referencia lo elaborado en el ejercicio 6 de la práctica de Escenarios:

• a) Indique las tácticas con las que resolvería estos escenarios. Justifique.

Vistas y Viewtypes

Bibliografía recomendada: Libro “Documenting Software Architecture – Views and Beyond” (Clements, Bachmann, Bass, Garlan) , Parte I, Capítulos 1 al 5.

7. Viewtypes

• 1. ¿Qué estilos conoce para cada viewtype? Describir los elementos, relaciones, propiedades y topología de cada estilo.
• 2. ¿Cómo se relacionan los viewtypes entre sí?

1)

Estilos - Viewtype Modulos

	Elements	Relations	Prop. of elements	Prop. of relations	Topology
Decomposition	Module, as defined by the module viewtype. A module that aggregates other modules is sometimes called a subsystem.	The decomposition relation, which is a refined form of the is-part-of relation. A documentation obligation includes specifying the criteria used to define the decomposition.	As defined by the module viewtype	Visibility, the extent to which the existence of a module is known, and its facilities are available, to those modules outside its parent.	No loops are allowed in the decomposition graph. A module cannot be part of more than one module in a view
Uses	Module as defined by the module viewtype.	The uses relation, which is a refined form of the depends-on relation. Module A uses module B if A depends on the presence of a correctly functioning B in order to satisfy its own requirements.	As defined by the module viewtype.	The uses relation may have a property that describes in more detail what kind of uses one module makes of another.	The uses style has no topological constraints. However, if loops in the relation contain many elements, the ability of the architecture to be delivered in incremental subsets will be impaired.
Generalization	Module, as defined by the module viewtype	Generalization, which is the is-a relation as in the module viewtype.	Besides the properties defined for a module in the module viewtype, a module can have the "abstract" property, which defines a module with interfaces but no implementation.	The generalization relation can have a property that distinguishes between interface and implementation inheritance. If a module is defined as an abstract module—the abstract property—restricting the generalization relation to implementation inheritance is not meaningful.	A module can have multiple parents, although multiple inheritance is often considered a dangerous design approach. Cycles in the generalization relation are not allowed; that is, a child module cannot be a generalization of one or more of its parent modules in a view.
Layered	Layers.	Allowed to use, which is a specialization of the module viewtype's generic depends-on relation. P1 is said to use P2 if P1's correctness depends on a correct implementation of P2 being present.	Name of layer. The units of software the layer contains. The software a layer is allowed to use. This property is documented in two parts. The first part gives the inter- and intra-layer usage rules; such as "a layer is allowed to use software in any lower layer," and "software is not allowed to use other software in the same layer." The second part names any allowable exceptions to those rules. The cohesion of the layer: a description of the virtual machine represented by the layer.	As for the module viewtype.	If layer A is above layer B, then layer B cannot be above layer A. Every piece of software is allocated to exactly one layer.

Estilos - Viewtype C&C

	Elements	Relations	Comput. Model	Prop.	Topology
Pipe&Filter	Component types: filter. Filter ports must be either input or output ports. Connector types: pipe. Pipes have data-in and data-out roles.	Attachment relation associates filter output ports with data-in roles of a pipe and filter input ports with data-out roles of pipes and determine the graph of interacting filters.	Filters are data transformers that read streams of data from their input ports and write streams of data to their output ports. Pipes convey streams of data from one filter to another.	Same as defined by the C&C viewtype.	Pipes connect filter output ports to filter input ports. Specializations of the style may restrict the association of components to an acyclic graph or a linear sequence.
Shared Data	Component types: shared-data repositories and data accessors. Connector types: data reading and writing.	Attachment relation determines which data accessors are connected to which data repositories.	Communication between data accessors is mediated by a shared-data store. Control may be initiated by the data accessors or the data store.	Same as defined by the C&C viewtype and refined as follows: types of data stored, data performance-oriented properties, data distribution.	Data accessors are attached to connectors that are attached to the data store(s).
Publish-Subscribe	Component types: any C&C component type with an interface that publishes and/or subscribes to events. Connector types: publish-subscribe.	Attachment relation associates components with the publish-subscribe connector.	A system of independent components that announce events and react to other announced events.	Same as defined by the C&C viewtype but refined as follows: which events are announced by which components and which events are subscribed to by which components, and when components are allowed to subscribe to events.	All components are connected to an event distributor that may be viewed as either a bus—connector—or a component.
Client-Server	Component types: client, which requests services of another component, and server, which provides services to other components. Connector types: request/reply, the asymmetric invocation of server's services by a client.	Attachment relation associates clients with the request role of the connector and servers with the reply role of the connector and determines which services can be requested by which clients	Clients initiate activities, requesting services as needed from servers and waiting for the results of those requests.	Same as defined by the C&C viewtype but refined by the server: the numbers and types of clients that can be attached and performance properties, such as transactions per second.	In general, unrestricted. Specializations may impose restrictions: Numbers of attachments to a given port or role Allowed relationships among servers Tiers
Peer-2-Peer	Component types: peers. Connector types: invokes procedure.	The attachment relation associates peers with invokes-procedures connectors and determines the graph of possible component interactions	Peers provide interfaces and encapsulate state. Computation is achieved by cooperating peers that request services of one another.	Same as defined by the C&C viewtype, with an emphasis on protocols of interaction and performance-oriented properties. Attachments may change at runtime.	Restrictions may be placed on the number of allowable attachments to any given port, or role. Other visibility restrictions may be imposed, constraining which components can know about other components.
Communicating Processes	Component types: concurrent units, such as tasks, processes, and threads Connector types: data exchange, message passing, synchronization, control, and other types of communication	The attachment relation, as defined in the C&C viewtype	Concurrently executing components that interact via the specific connector mechanisms	Concurrent unit: preemptability, which indicates that execution of the concurrent unit may be preempted by another concurrent unit or that the concurrent unit executes until it voluntarily suspends its own execution; priority, which influences scheduling; timing parameters, such as period and deadline Data exchange: buffered, which indicates that messages are stored if they cannot be processed immediately, or protocol, used for communication	Arbitrary graphs

Estilos - Viewtype Allocation

	Elements	Relations	Prop. of elements	Prop. of relations	Topology
Deployment	Software element, usually a process from the C&C viewtype Environmental elements: computing hardware—processor, memory, disk, network, and so on	Allocated-to, showing on which physical units the software elements reside Migrates-to, copy-migrates-to, and/or execution-migrates-to if the allocation is dynamic	Required properties of a software element: the significant hardware aspects, such as processing, memory, capacity requirements, and fault tolerance Provided properties of an environmental element: the significant hardware aspects that influence the allocation decision	Allocated-to relation: either static or dynamic, as discussed in Section 6.4	Unrestricted
Implementation	Software element: a module Environmental element: a configuration item, such as a file or a directory	Containment, specifying that one configuration item is contained in another Allocated-to, describing the allocation of a module to a configuration item	Required properties of a software element, if any: usually, requirements on the developing environments, such as Java or a database Provided properties of an environmental element: indications of the characteristics provided by the development environments	None	Hierarchical configuration items: is-contained-in
Work Assignment	Software element: a module Environmental element: an organizational unit, such as a person, a team, a department, a subcontractor, and so on	Allocated-to	Skills set: required and provided	None	In general, unrestricted; in practice, usually restricted so that one module is allocated to one organizational unit

2)

The most interesting relationship concerning C&C views is how they map to a system’s module views. The relationship between a system’s C&C views and its module views may be complex. The same code module might be executed by many of the elements of a C&C view. Conversely, a single component of a C&C view might execute code defined by many modules. Similarly, a C&C component might have many points of interaction with its environment, each defined by the same module interface.

8. HousiHome ++

Tomando como referencia lo elaborado en el ejercicio 4 de la práctica de Escenarios, proponer una o dos tácticas para los escenarios descritos y mostrar modelos de la arquitectura para las viewtypes Modular, C&C y Alocación.

9. Bolsa de Comercio

Tomando como referencia lo elaborado en el ejercicio 5 de la práctica de Escenarios:

• a) Realice un diagrama de C&C de la aplicación. ¿Qué viewtypes utilizaría? Justifique
• b) Realice un diagrama de alocación. ¿Qué viewTypes utilizaría? Justifique

10. Tiendas de ropa

El siguiente diagrama representa una vista C&C de la arquitectura del sistema informático de una cadena de tiendas de ropa.

UI Tesorería provee medios al usuario de la tienda para acceder a las operaciones de Fondos, Recaudaciones y la registración de Z física al cierre del día. Los Business App Server 1..3 son alojados en diferentes equipos en el data center de la oficina central.

La registración de Z física contempla registrar datos de las Z de cada caja que incluye la siguiente información:

• Tienda (4 bytes), caja (4 bytes) y Id de Z (12 bytes)
• Valor total de venta diaria en moneda fiscal (12 bytes: 10 parte entera y 2 decimales)
• Imagen de Z (150 Kbytes)

La registración de la Z física se realiza a partir de las 24 hs luego de que todos los cajeros han finalizado sus rendiciones. Los valores resultantes de los movimientos de fondos, recaudaciones y depósitos es utilizado por procesos nocturnos que son programados por los usuarios de la central durante el día, y son ejecutados por alguno de los componentes Business App Server 1..3. El conector entre la UI Tesorería y alguno de los Business App Server transfiere datos a través de la red WAN, cuyo nivel de servicio sabemos es posible no esté disponible luego de las 24 hs debido a regulares actividades de mantenimiento. A partir de la condición anteriormente expuesta:

• a) Describa el escenario de disponibilidad de los servicios de registro de Z física presente ante la caída de la WAN.
• b) Proponga el conjunto de cambios mínimo en el diseño del diagrama de modo de cumplir con el escenario descrito.

11. En el horno…

El presente ejercicio contempla el diseño de la arquitectura de un sistema de control de un horno de cobre. El propósito de este horno es la depuración del cobre bruto a partir del calentamiento de la materia prima, en pos de separar las impurezas convertidas en escoria y sedimento, del material de mayor pureza. El cobre puro pierde su estado sólido entre los 1083 y 1084 grados centígrados a presión normal. Parte de las impurezas se evaporan a esa temperatura con mismas condiciones de presión, parte se licuan flotando sobre el cobre puro, y parte permanecen en estado sólido. El horno posee válvulas que conservan la presión bajo condiciones normales y liberan los vapores producidos por la purificación de parte de la materia prima. Adicionalmente posee una compuerta a nivel superficial del cobre que permite la eliminación del material flotante sobre superficie del cobre puro, y otra para obtener el cobre puro una vez que tanto el material superficial como los vapores impuros han sido eliminados. Una vez extraído el cobre es eliminada del fondo del horno el material residual sólido. Además del horno existe un canal de recolección de cobre, otro de recolección de impurezas y otro que es utilizado ante emergencias para recolectar el material a medio procesar que es extraído como proceso de contingencia ante una situación crítica (canal de recuperación de material). El horno debe poseer un sistema de control de temperatura, otro de presión, un sistema que reacciona a la temperatura enfriando o calentando el horno y otro que reacciona a la presión abriendo o cerrando válvulas. La pérdida de control sobre cualquiera de estas variables pueden producir situaciones de riesgo para la vida de las personas, con lo cual debe existir un sistema de monitoreo que ante situaciones de presión o temperatura fuera de control, debe vaciar el contenido del horno sobre el canal de recuperación de material, enfriar el mismo, registrar las condiciones finales de monitoreo y disparar una alarma para que el personal desaloje la salas próximas al mismo. Esta es una situación de contingencia no deseable y se debe evitar por todos los medios llegar a la misma. Las condiciones del horno son registradas cada 3 segundos en pos de analizar escenarios de falla y estudiar posibles fallas de diseño fundamentales del mismo en base a esta información. Los datos recolectados son conservados en un repositorio seguro para tal propósito. La información sobre cantidad de impurezas extraídas, cantidad de materia pura sobre cantidad de materia ingresada al horno es también relevante para medir la calidad de la materia prima y deben ser registradas para su análisis.

• a) Identifique los subsistemas del dominio.
• b) Especifique los 3 escenarios más relevantes de acuerdo a su criterio.
• c) Especifique el modelo de C&C asociado con el sistema descrito.
• d) Indique situaciones de alocación que identifica como arquitecto para la construcción del horno.

(1) La Z de una caja contiene el registro de todas las operaciones llevadas a cabo por la caja.

12. Fútbol de robots

El presente ejercicio contempla el diseño de la arquitectura de un sistema de control de fútbol de robots. El propósito de este sistema es competir en un juego donde una serie robots físicos compiten por convertir la mayor cantidad de goles contra otro sistema idéntico a nivel físico (misma cantidad de piezas, mismo espacio de juego, misma configuración de cancha y pelota compartida) El espacio de juego o cancha consiste en un marco de 200 cm x 100 cm, dos espacios de “arco” que son sensores de 40 cm dispuestos en cada lado de 100 cm de la cancha, y donde un objeto distinguido como la pelota se desliza a partir del impacto ejercido por los robots. Estos elementos pertenecen a la infraestructura común provista por la organización de la competencia. Cada equipo provee para la competencia su propia infraestructura de juego consistente de 3 jugadores, una cámara de monitoreo para identificar el posicionamiento de los jugadores y de la pelota en la cancha, y un sistema que recibe las imágenes de esta cámara y toma decisiones para indicar sobre las movidas tácticas a los robots jugadores en pos de convertir la mayor cantidad de goles e imposibilitar que el equipo contrario convierta los propios. Cada uno de los 3 robots de cada equipo es distinguido con una cantidad de puntos en rojo o azul que distinguen por color a los equipos, y por la cantidad de puntos a un robot de otro dentro del mismo equipo para el sistema de control; la pelota es por otro lado coloreada con negro. Un gol es convertido cuando uno de los 3 robots de algún equipo consigue que la pelota impactada “toque” uno de los arcos. Cada arco es asignado a uno de los equipos y el sistema que coordina el juego es responsable de controlar los tiempos de juego, y contar la cantidad de goles que cada uno de los equipos va convirtiendo. La cámara común genera 3 imágenes por segundo, las cuales son entregadas en forma simultánea a cada sistema de control de robots quienes las someten dos acciones: identificar la posición de la pelota e identificar la posición de todos los jugadores (propios y contrarios). La identificación de la posición de la pelota se basa en aplicar un algoritmo de filtro que detecta el negro de la pelota por encima de los otros colores en forma eficiente. Esta identificación es optimizada al reducir la porción de la imagen a procesar al mínimo posible en función del conocimiento de la posición de la pelota que se tiene en base al procesamiento previo. Gracias a esta optimización es posible computar una porción de imagen por señal recibida (> 3 computaciones por segundo de filtro). De no encontrarse la pelota en el espacio buscado se procede a buscar sobre toda la imagen de cancha en pos de localizar la pelota lo cual demora aproximadamente 1 segundo (3 señales de cámara).

La identificación de los robots se realiza a partir de aplicar un filtro de rojos y azules (dos filtros) demorando cada una 1 segundo. Esto hace que se pueda identificar el estado de posición de jugadores cada 6 muestreos de la cámara. Se requiere que el sistema que controla la estrategia del juego de cada equipo guíe a los robots a convertir la mayor cantidad de goles posibles y evitar que el contrario haga los propios, a partir de guiar a los robots a través de sus actuadores de dirección y velocidad.

a) Identifique los subsistemas del dominio, identifique (no hace falta especificarlos) los 3 escenarios más relevantes de acuerdo a su criterio, y especifique el modelo de C&C asociado con el sistema descrito.

13. Aplicación de compilación

Se desea construir una aplicación de compilación. Por cada iteración proveer vistas del module viewtype que capturen (si es posible) las decisiones tomadas para atender las restricciones y atributos de calidad. Indicar si la nueva iteración involucra cambios en vistas de la iteración anterior.

• 1er iteración:

La compilación consiste en el parsing y construcción del árbol de sintaxis abstracta (AST), la transformación de ese árbol y su posterior escritura. Existe una interfaz gráfica de usuario (GUI) que provee al usuario de la aplicación del control y visualización de la compilación. El compilador brinda a la GUI funciones para proveer la entrada y la salida del compilador. Se espera que la transformación del AST varíe a lo largo de la vida de la aplicación debido a la optimización de su algoritmo.

• 2da iteración:

Tanto el parsing como la escritura hacen uso de un módulo de I/O. Además de la GUI, la aplicación se distribuirá en una versión alternativa donde el usuario interactúa a través de la línea de comando. Se espera que a lo largo de la vida de la aplicación se construyan nuevos refinamientos de la UI.

• 3er iteración:

Se adquiere un módulo off-the-self especializado en la administración y almacenamiento eficiente (en memoria) de los AST's (llamado "SmartAST"). únicamente se debe acceder al mismo para el parsing, la escritura y la traducción. El uso de SmartAST no está permitido para el resto de los módulos ajenos a estas responsabilidades.

Hint: Repasar los estilos de vistas del module viewtype (Decomposition, Uses, Generalization, Layered).

14. CMS

Un Sistema de gestión de contenidos (Content Management System, en inglés, abreviado CMS) permite la creación y administración de contenidos principalmente en páginas web. Consiste en una interfaz que controla una o varias bases de datos donde se aloja el contenido del sitio. El sistema permite manejar de manera independiente el contenido y el diseño. Así, es posible manejar el contenido y darle en cualquier momento un diseño distinto al sitio sin tener que darle formato al contenido de nuevo, además de permitir la fácil y controlada publicación en el sitio a varios editores. Un ejemplo clásico es el de editores que cargan el contenido al sistema y otro de nivel superior que permite que estos contenidos sean visibles a todo público.

• a) Caracterice con un escenario un atributo de calidad del sistema.
• b) Proponga al menos dos tácticas complementarias para controlar el atributo.
• c) Refleje el uso de esas tácticas en las vistas correspondientes de los viewtypes C&C, Alocación y Modular.

15. Red de Cajeros Automáticos

Se desea realizar un sistema para manejar una red de cajeros automáticos en las cual hay muchos cajeros automáticos y dos bancos: el A y el B. Ambos bancos poseen el mismo comportamiento. Este sistema sólo permite realizar extracciones de dinero, para las cuales hay un monto máximo de 1000 unidades de dinero por extracción. Las extracciones de dinero, como se explica con más detalle luego, deben ser informadas lo antes posible al banco respectivo. Cada uno de los bancos puede estar en dos estados: online u offline. Si está online, puede recibir consultas y novedades de las extracciones por parte del administrador de la red. En caso de estar un banco offline, no hay posibilidad de que el administrador se comunique en ese momento con dicho banco. Los avisos de cambios de estado (de online a offline o de offline a online) son comunicados por un banco, y los mismos pueden llegar al administrador en cualquier momento. Pero es muy importante que el aviso sea tratado en ese mismo instante, sin que eso implique detener la operatoria normal del administrador. Los cajeros automáticos son responsables de obtener el número de cuenta y luego pedir el ingreso del pin (es una password) y del monto a extraer. Se comunican con el administrador de la red para primero autenticar la cuenta/pin y luego chequear que el monto a extraer sea aceptado. El administrador de la red es el que autentica las cuentas/pines. El número de cuenta permite identificar unívocamente a un banco y una cuenta dentro del sistema bancario. Si el banco correspondiente está online, el administrador debe chequear que el monto a extraer no exceda el saldo de la cuenta, y la extracción es comunicada al banco de manera inmediata. Si el banco correspondiente está offline, siempre se autoriza la extracción, y las extracciones se comunican al banco correspondiente en cuanto el banco pase a estar online. Un requerimiento importante es que todas las extracciones deben ser comunicadas al banco que corresponda, y cada extracción debe ser comunicada una sola vez. Notar que puede existir un retardo entre que el banco envía su estado y la recepción del mismo por parte del administrador, por lo cual podría ocurrir que este haya enviado un pedido de extracción a una cuenta y el banco ya se encuentre offline. Suponer que si ante un pedido el banco no responde en una cantidad determinada de tiempo, ese pedido se considere como si el banco estuviera offline. De todas formas se le deberá notificar al banco de la cancelación del mismo pues este podría estar efectivamente online y el retardo podría haber sido causado por algún otro motivo. Tomar alguna decisión con las situación opuesta, es decir con respecto al retardo que existe entre que el banco pasa a estar online y la llegada del nuevo estado al administrador.

• a) Identifique los 3 escenarios principales e indique las tácticas que utilizaría para resolverlos.
• b) Realice un diagrama de Componentes & Conectores. ¿Qué viewtypes utilizaría? Justifique
• c) Realice un diagrama de Módulos. ¿Qué viewtypes utilizaría? Justifique

16. Control de tránsito

La dirección de tránsito de la ciudad, a fin de modernizar y hacer más eficiente el control de infracciones, ha decidido implementar un nuevo sistema para detectar el paso de semáforos en rojo de los vehículos. El sistema consiste de varios dispositivos que interactúan entre sí, y otros sistemas ocupados de elaborar las multas. En primer lugar, se colocará en bocacalles estratégicas de la ciudad unas cintas bajo el asfalto, a lo largo de la senda peatonal. Estas cintas poseen unos sensores colocados cada 10 cm., que detectan el paso de un tren de ruedas sobre la cinta, pudiendo además indicar la posición absoluta de dichas ruedas en la cinta. Además, se montarán a lo largo de la línea peatonal varias cámaras digitales, con separación de 50 cm., para que saquen fotos de los autos infractores. Cada cámara tiene un rango angular de 1 m. hacia cada lado, por lo que hay redundancia entre las mismas. Las cámaras poseen conexión wi-fi para el envío y recepción de datos. Finalmente, existe un controlador de semáforos que actualmente está programado para que cicle entre rojo y verde cada un minuto, aunque este intervalo puede cambiarse. Este controlador posee interfaces que permiten preguntar el estado del semáforo en cualquier momento. Como se marcó anteriormente, los sensores son muy rudimentarios: sólo detectan el paso de un tren de ruedas y, dado que están montados sobre la senda peatonal, puede darse el caso de que un auto sobrepase la misma, pero no cruce el semáforo. A los efectos prácticos, el sistema deberá informar el paso de un auto si los sensores detectan el paso de dos trenes de ruedas por el mismo sensor, o por dos sensores adyacentes en un intervalo de 2 segundos (por ejemplo, si el sensor 1 detecta ruedas y en menos de dos segundos el sensor de al lado detecta ruedas, se debe considerar que pasó un auto por ese lugar). La interpolación de los datos permitirá ubicar al auto con la mayor precisión posible. Las cámaras están montadas de manera tal que apuntan al centro de la bocacalle, por lo que debe tenerse en cuenta la velocidad del auto infractor para tomar correctamente la foto. Por otra parte, hay que considerar que el tiempo de recarga de la cámara es de 5 segundos, tiempo durante el cual está inutilizable y habrá que utilizar una cámara alternativa para tomar la foto en caso de ser necesario. Se desea minimizar el número de fotos perdidas por estar recargando las cámaras. Los sensores, semáforos y cámaras, junto con sus controladores, fueron comprados cerrados, sin posibilidad de ser modificados, aunque con la documentación de sus interfaces completa. Los sensores sólo pueden ser programados para que indiquen el paso de ruedas por encima de ellos, mientras que las cámaras solo proveen la posibilidad de sacar fotos instantáneas (no tienen timer), y deben configurarse para enviar automáticamente las fotos al servidor de procesamiento de infracciones, donde se combinará automáticamente la información de las patentes con el legajo del dueño del vehículo según la información de dominio.

• a) Utilice los diagramas que considere necesarios para mostrar la arquitectura del sistema de manera detallada, explicando y justificando las decisiones tomadas.
• b) Especifique mediante escenarios los atributos de calidad referidos a performance y disponibilidad del sistema (invente un parámetro ficticio para la cantidad de fotos perdidas admisibles, explique el mecanismo por el cual se podría satisfacer el requerimiento).