Desarrollo De Software

3. Construcción.
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
elpunto 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 ylos
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 lascualidades 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 princip ales, como el flujo de control, control de
acceso y almacenamientode 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 seasigna a un equipo y se realiza en forma indepen diente. 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 quefuncionalidad?
¿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?
50 50
• 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
maneradiná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 l a 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.
Los grandes sistemas siempre se descomponen en subsistemas queproporcionan 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...