Edición de «Práctica de Tacticas y Viewtypes (Ingeniería II)»

__NOTOC__
{{Back|Ingeniería de Software II}}

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

=Tacticas=
 
==1. Tac - tic - tac - tic - … ==
<b> 
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? 
</b>

{| border="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. Disponibilidad==
<b> 
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. 
</b>

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 ==
<b> 
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. 
</b> 
  
==4. Seguridad ==
<b> 
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? 
</b> 
 
==5. Usabilidad ==
<b> 
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. 
</b> 
 
==6. Casinopolis ==
<b> 
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. 
</b> 

=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 ==
<b> 
*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í? 
</b> 

1)

{| border="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.
|}

{| border="1"
|+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
|}

{| border="1"
|+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 ++ ==
<b> 
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. 
</b> 
 
==9.  Bolsa de Comercio ==
<b> 
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 
</b> 
 
==10. Tiendas de ropa ==
<b> 
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. 
</b> 
 
==11. En el horno… ==
<b> 
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. 
</b> 
 
==12. Fútbol de robots ==
<b> 
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. 
</b> 
 
==13. Aplicación de compilación ==
<b> 
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). 
</b> 
 
==14. CMS ==
<b> 
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. 
</b> 
 
==15. Red de Cajeros Automáticos ==
<b> 
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 
</b> 
 
==16.  Control de tránsito ==
<b> 
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). 
</b> 

[[Category:Prácticas]]