Capítulo 1: Conceptos básicos de arquitectura de software 1

Identificar el problema a resolver

A medida que define la arquitectura de software, la pregunta más importante que hay que hacer es: “¿Qué
problema estoy resolviendo” Una de las razones principales por las que los sistemas de software no tienen
éxito es que no se ajustan a las necesidades del cliente o cliente que solicitada el software. En otras
palabras, ellos no resuelven el problema del cliente o del cliente.

En esta sección, te muestro cómo identificar el problema para que pueda desarrollar una solución que tanto
resuelve el problema y cumple con las necesidades del cliente de su cliente o de.

Rompiendo el problema en los

cuatro atributos
Los problemas que se resuelven con la arquitecturas de software tienen cuatro atributos principales:

✓ Función: Describe el problema a resolver

✓ Formar: Describe la forma de la solución y cómo encaja en el bientes

ronment de otros sistemas y tecnologías

✓ Economía: Describe cuánto cuesta construir, operar y mantener

la solución

✓ Hora: Describe cómo se espera que el problema de cambiar en el futuro

La comprensión de estos cuatro atributos es crítica para la identificación del problema a resolver.
 Capítulo 1: Conceptos básicos de arquitectura de software 2
Preguntar al cliente lo que quiere en un sistema y por qué lo quiere. Como él mismo explica, tomar notas, y
asignarlos a estos atributos de problemas.

En última instancia, el sistema descrito por su arquitectura debe hacer lo que quiere el cliente, a un costo
que el cliente está dispuesto a pagar, y en un horario que satisface las necesidades del cliente.

El desarrollo de un planteamiento del problema

Es necesario un planteamiento del problema para entender qué construir.

Para mostrar que la forma de desarrollar un planteamiento del problema, comienzo a caminar a través del proceso de
creación de un ejemplo de sistema de nómina. Sigue estos pasos:

1. Establecer los objetivos del proceso de definición del problema.

Decidir el tiempo que puede pasar desarrollar el enunciado del problema y el grado de detalle el
planteamiento del problema tiene que tener.

Para un sistema de nómina, que quiere identificar las limitaciones en la solución (cuestiones que
afectan a su forma, la economía, y el tiempo) y asegúrese de que entiende la función de alto nivel: para
que los empleados pagados.

2. Recabar la información.

En las etapas de recolección de hechos, se trabaja con el cliente o cliente para entender sus
necesidades, cómo está la satisfacción de esa necesidad ahora, y qué plataforma informática que
espera para ser utilizado en la solución. También identificar a las personas y otros sistemas,
conocidos como actores, que va a interactuar con el sistema. Su objetivo es averiguar lo más que
pueda sobre el problema, la necesidad, y las expectativas sobre el sistema.

Por ejemplo, el sistema de nómina, se tenga que reunir datos sobre el número de empleados, la
frecuencia con que se les paga, cómo se calcula su pago, y qué potencial se toman las
deducciones de su paga.

3. Descubrir los conceptos que son esenciales para la solución y que la voluntad
dar forma a su arquitectura.

En este paso, usted busca los conceptos subyacentes en juego. A descubrir supuestos, ecuaciones, los
reglamentos, los modelos de procesos, las limitaciones de uso y otros conceptos fundamentales.

Para el sistema de nómina, a descubrir las ecuaciones usadas para calcular la paga de un
empleado y determinar cómo las irregularidades de pago normales se comunican con el sistema.

4. Determinar lo que el cliente o cliente debe tener que contentarse con

la solución.

Este paso implica la comprensión de las necesidades y expectativas del cliente o cliente basado
en los conceptos subyacentes que encontró en el paso 3.
 Capítulo 1: Conceptos básicos de arquitectura de software 3
¿Cuál es el mínimo que el cliente debe tener para ser feliz con la solución a diseñar?

El ejemplo de sistema de nómina tiene que tomar en horas trabajadas de cada empleado, para conocer el
tipo de base de la remuneración y deducciones relacionadas, y para calcular las cantidades de pago. El
sistema también tiene que imprimir cheques o de alguna otra manera hacer pagos a los empleados.

5. Escribir el enunciado del problema.

Sobre la base de su comprensión del problema de completar los cuatro pasos anteriores, puede
escribir una declaración del problema que trae en los cuatro atributos de la función, la forma, la
economía, y el tiempo (ver la sección anterior) de una manera que lo explica al cliente o cliente.

Para el sistema de nómina ejemplo, el planteamiento del problema es “Calcular y pagar a los empleados
por el trabajo realizado [Función] utilizando un sistema interactivo para la introducción de las horas
trabajadas y para hacer el pago a través de depósito directo [Formulario]. La solución debe estar
disponible en tres meses [hora] para el precio negociado [Economía] “.

La definición de los casos de uso importantes

Cuando se tiene una idea clara de cuál es el problema, que desea afinar esa definición y realmente hacer un
zoom sobre lo que hay que hacer para resolver el problema. Una forma efectiva de hacer esto es escribir casos
de uso. UNA caso de uso describe lo que una persona debe esperar para llevar a cabo cuando él o ella utiliza el
sistema. actores - las personas u otros sistemas que interactúan con el sistema que está siendo diseñado - son
los principales ingredientes en los casos de uso, y que discutan por separado más adelante en esta sección.

Los escenarios que se muestran en los casos de uso se conectan los diferentes puntos de vista de la arquitectura, que
muestra cómo las partes de la obra de arquitectura en conjunto para resolver los problemas que ha identificado mediante la
descripción de escenarios de uso de ejemplo.

La elección de la funcionalidad de captura

Usted escribe un caso de uso para explicar cómo algunas de las funciones del sistema de trabajo y la forma en
que el sistema interactúa con los actores. Los casos de uso se pueden utilizar para explicar la funcionalidad
externa o lo que sucede en el interior del sistema. La funcionalidad externa es lo que se quiere entender en esta
etapa de su desarrollo de la arquitectura, por lo que concentrarse en las interacciones de los actores externos
con el sistema. A medida que desarrolla su arquitectura, utilizando el método que explico en el capítulo 2, las
funciones internas del sistema se vuelven claras.

Los casos de uso pueden capturar funcionalidad grande, como el cálculo de nómina semanal para todos los empleados, o la
funcionalidad pequeñas, tales como la validación de las horas trabajadas por un solo empleado. Independientemente del
tamaño, sin embargo, todos los casos de uso tienen objetivos discretos - resultados específicos que describen.
 Capítulo 1: Conceptos básicos de arquitectura de software 4
Para ver cómo funcionan los casos de uso, tenga en cuenta el sistema de nómina sencilla de la sección
anterior que calcula los pagos debidos y dirige esos pagos. La Figura 1-2 muestra un diagrama de casos
de uso para este sistema y el texto que describe el caso de uso. Ambas partes son importantes. Este caso
de uso tiene un actor - el empleado - que está interactuando con el sistema para actualizar las horas que
trabajó.

Figura 1-2:
Un ejemplo
use el

diagrama del caso.

diagramas de casos de uso como el que se muestra en la Figura 1-2 son útiles para proporcionar una visión
general de cómo los actores interactúan con el sistema y entre sí.

No trate de capturar todos los detalles en un solo caso de uso. Si lo hace, el caso de uso será difícil de
manejar.

Desarrollar los casos de uso un poco a la vez. Empieza por escribir un caso de uso de alto nivel y luego añadir
más casos de uso que van en mayor detalle.

La identificación de los actores

Los casos de uso giran en torno a los actores. ¿Quiénes son estos actores? Aquí hay algunas definiciones:

✓ Actores realizar las funciones descritas en el caso de uso.

✓ Actores desempeñan diversas funciones: cliente, usuario, empleado, encargado, nómina

secretario, y así sucesivamente.
 Capítulo 1: Conceptos básicos de arquitectura de software 5
✓ Los actores pueden estar involucrados en muchos casos de uso. actores particulares, como el
empleado de la nómina, puede realizar diferentes funciones en diferentes casos de uso.

✓ Los actores no necesitan ser humano; pueden ser otros sistemas.

Cuando un actor es un sistema, usar un símbolo diferente en el diagrama de casos de uso de la que se utiliza
para el ser humano (ver la siguiente sección).

✓ actores no humanos no deben ser componentes internos del sistema.

Los actores son personas o cosas que interactúan con el sistema desde su exterior. A los
efectos de casos de uso, el sistema es un cuadro negro, y no debe incluir su funcionamiento
interno.

La diagramación del sistema

Los sistemas tienen múltiples casos de uso, por lo que un diagrama especial caso de uso proporciona una vista de alto
nivel de cómo todos los actores interactúan con el sistema y sirve como una tabla de contenidos para los casos de uso
individuales.

La Figura 1-3 muestra el diagrama de casos de uso para todo un sistema de nómina. El sistema de nómina está
en el centro, rodeado de los actores. Las burbujas representan los casos de uso con nombre.

Figura 1-3:
Un diagrama de

casos de uso para

una

arquitectura entero.
 Capítulo 1: Conceptos básicos de arquitectura de software
6
La documentación de los casos de uso
Al empezar a definir los casos de uso, comenzar en el nivel visión general de identi ficar los casos
de uso más importantes; a continuación, dirija su atención a refinar estos casos de uso.
Documentarlos mediante el proceso que sigue.

Estos nueve pasos, que describen las tareas necesarias para desarrollar un caso de uso, son de UML 2
para los maniquíes, por Michael Jesse Chonoles y James A. Schardt (Wiley):

1. Decidir qué casos de uso que va a documentar, y darle una

nombre.

2. Dibuje un diagrama que muestra cómo interactúan los actores

con el sistema.

Para un ejemplo, consulte la Figura 1-2, anteriormente en este capítulo.

3. Escribir un breve resumen del caso de uso.

Por lo general, una frase o dos es suficiente.

4. Escribir la historia del caso de uso.

La historia por lo general comienza con “El actor hace alguna cosa. ”

5. Describir la secuencia principal de los acontecimientos que sucederán después de la

el actor comienza el caso de uso.

6. Anote todo lo que se debe hacer antes de que el caso de uso

Pone en marcha y que se debe hacer después de que termine.

7. Identificar a los otros escenarios, como los casos de error o alternativas.

8. Escribir las secuencias de eventos para los escenarios alternativos

identificado en el Paso 7.

9. Añadir cualquier regla que el caso de uso debe cumplir.

Es posible que desee agregar una regla que se requiere que el caso de uso para validar la entrada de
datos por un actor, por ejemplo.

La elección de un estilo de Software System

En el capítulo 2, se obtiene a la tarea de crear la arquitectura de software real. Antes de hacerlo,
en el último paso antes de la inmersión y el diseño-ing la arquitectura del sistema, es necesario
empezar a pensar acerca de qué tipo

de estilo y forma el sistema debe tener. En esta sección, destaco dos aspectos del estilo del
sistema: arquitectura y programación.

Estilos arquitectonicos
Los estilos arquitectónicos definen la forma general del sistema. En la vivienda residencial, Cape
Cod y el rancho son ejemplos de estilos arquitectónicos. En la arquitectura soft- ware, estilos
incluyen Modelo-Vista-Controlador y Tubos y filtros. Me presento software estilos de arquitectura
en la Parte III.

En los diferentes modelos de la arquitectura (como el modelo de 4 + 1 se muestra en la Figura 1-1,

anteriormente en este capítulo), las vistas están relacionados pero también indepen-

abolladura. Es posible que desee utilizar un estilo arquitectónico diferente dentro de cada punto de
vista.
 Capítulo 1: Conceptos básicos de arquitectura de software
7

estilo de programación
También debe considerar su estilo de programación - estilo basado en objetos, estilo cedural pro,
o estilo funcional, por ejemplo. No todos los problemas se adapta a todos los estilos de
programación, por lo que estar familiarizado con varios estilos es esencial para entender el estilo
de programa que debe utilizar y elegir el más adecuado para el problema y la solución.

No voy a tratar de explicar las diferencias o influir en su decisión. amplios recursos acerca de la programación en
cualquiera de estos estilos están disponibles, incluyendo muchos Para Dummies libros, y estoy seguro de que usted
tiene sus propios estilos preferidos. A pesar de que este libro es acerca de los patrones, sin embargo, no es
exclusivamente acerca de la programación orientada a objetos. Los patrones no son siempre para los objetos. Como
se puede ver en los capítulos siguientes (en concreto, los capítulos 8, 23 y 24), los patrones están disponibles para
una amplia gama de problemas, no todos los cuales se refieren a objetos.