Construccion

Contenido

3. Construcción (Primer Autor). 1

3.1 Despliegue de componentes y arquitectónico (Primer Autor). 3

3.2 Técnicas de desarrollo de las arquitecturas de referencia en diferentes dominios (Primer Autor). 8

3.2.1 Los modelos de componentes (Primer Autor). 10

3.2.2 Arquitectura de referencia para sistemas de tiempo real fuente de alimentación (Primer Autor). 16

3.2.3 Arquitectura de referencia para sistemas móviles con conexión a Internet (Primer Autor). 19

3.2.4 Arquitectura de referencia para sistemas de información (Primer Autor). 25

3.2.5 Arquitectura de referencia para ambientes virtuales de aprendizaje (Primer Autor). 31

3.2.6 Arquitecturas de referencia para líneas de productos (Primer Autor). 36

3. Construcción (Primer Autor).

El análisis da como resultado el modelo de requerimientos descrito por los siguientes productos:

• Un conjunto de requisitos no funcionales y las limitaciones, tales como el tiempo máximo de respuesta, rendimiento mínimo, confiabilidad, plataforma de sistema operativo, y así sucesivamente

• 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

El modelo de análisis describe el sistema completo desde el punto de los actores de vista y sirve como base de la 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, su configuración de hardware o, en términos generales, la manera en que se debe realizar. El diseño del sistema es el primero paso en esta dirección. El diseño del sistema da como resultado los siguientes productos:

• Una lista de objetivos de diseño, que describe las cualidades del sistema que los desarrolladores deben optimizar

• Una arquitectura de software, que describe la descomposición del subsistema en subsistemas desde el punto de vista de responsabilidades del subsistema, dependencias entre subsistemas, correspondencias de los subsistema con el hardware, y decisiones políticas principales, como el flujo de control, control de acceso y almacenamiento de datos.

Los objetivos de diseño se derivan de los requisitos no funcionales. Los objetivos de diseño guían las decisiones que deben tomar los desarrolladores, en especial cuando hay compromisos. La descomposición en subsistemas constituye la mayor parte del diseño del sistema. Los desarrolladores dividen el sistema en piezas manejables para hacer frente a la complejidad: Cada subsistema se asigna a un equipo y se realiza en forma independiente. Sin embargo para que esto sea posible, los desarrolladores necesitan atacar asuntos en el nivel de sistema cuando descomponen el sistema. En particular, necesitan atacar las siguientes cuestiones:

• Correspondencia entre Hardware y software: ¿Cuál es la configuración de hardware del sistema? ¿Cuál nodo es el responsable de que funcionalidad? ¿Cómo se realiza la comunicación entre los nodos? ¿Cuáles servicios se realizan utilizando componentes de software existentes? ¿Cómo se encapsulan estos componentes?

Administración de datos: ¿Cuáles datos deben ser persistentes? ¿Dónde se almacenan los datos persistentes? ¿Cómo se accede a ellos?

• Control de acceso: ¿Quién puede acceder a los datos? ¿Pueden cambiar manera dinámicamente el control de acceso? ¿Cómo se especifica y realiza el control de acceso? El control de acceso y la seguridad son asuntos en el nivel del sistema. El control de acceso debe ser consistente en todo el sistema, es decir, la política se utiliza para especificar quién puede y quién no puede acceder a ciertos datos debe ser la misma en todos los subsistemas.

• Control de flujo: ¿Cómo funciona la secuencia de las operaciones del sistema? El sistema es manejado por eventos? ¿Puede manejar más de una interacción del usuario a la vez?

• Condiciones de frontera: ¿Cómo se inicia el sistema? ¿Cómo se apaga? ¿Cómo se detectan y manejan los casos de excepción?

3.1 Despliegue de componentes y arquitectónico (Primer Autor).

Los grandes sistemas siempre se descomponen en subsistemas que proporcionan algún conjunto de servicios relacionados. El proceso de diseño inicial que identifica estos subsistemas y establece un marco para el control y comunicación de los subsistemas se llama diseño arquitectónico.

El resultado de este proceso de diseño es una descripción de la arquitectura del software.

El proceso de diseño arquitectónico está relacionado con el establecimiento de un marco estructural básico que identifica los principales componentes de un sistema y las comunicaciones entre estos componentes

Con el fin de reducir la complejidad del dominio de aplicación, se identificaron partes más pequeñas llamadas clases y las organizó en paquetes. Del mismo modo, para reducir la complejidad del dominio de solución, se descomponen un sistema en partes más simples, llamados subsistemas, que están constituidos por una serie de clases de del dominio solución. En el caso de subsistemas complejos aplicamos de forma reiterada este principio y se descomponemos en subsistema más simples un subsistema, ver Figura 3.1.

Figura 3.1 diagrama de clases

Ejemplo: en un sistema de gestión de accidentes los oficiales de campo, como por ejemplo, un oficial de policía o bombero, tiene acceso a una computadora inalámbrica que les permite interactuar con un despachador. El despachador, a su vez puede visualizar el estado actual de todos sus recursos, como por ejemplo, coches de policía o camiones, en una pantalla de computadora y despachar un recurso mediante la emisión de comandos desde una estación de trabajo. En este ejemplo, FieldOfficer y Dispatcher son actores.

Figura

...