-
Notifications
You must be signed in to change notification settings - Fork 1
/
arquitectura.tex
226 lines (188 loc) · 9.7 KB
/
arquitectura.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
\section{Introducción a la arquitectura}
\label{sec:arquitectura:intro}
Requerimientos \textrightarrow Diseño \textrightarrow Construcción
\textrightarrow Pruebas \textrightarrow Implantación.
\\
La arquitectura de Software de un sistema es el \textbf{conjunto} de
\textbf{estructuras} necesarias para \textbf{razonar} sobre el
sistema\footnote{Preguntado en el examen de 2017}. Relaciona distintos
elementos de software como son los objetos o los hilos de ejecución;
el modelo del sistema, los diagramas, la lógica; o las entidades
físicas como los nodos donde se ejecutará Software.
Desde una perspectiva de alto nivel, la arquitectura de Software cubre
diferentes componentes del sistema. Tendrá en cuenta los
requerimientos y fines del sistema, pero a la vez la creación del
modelo, las dependencias y los escenarios de uso. Es decir, la
arquitectura de software maneja sin encargarse de la implementación
final, los aspectos técnicos y de uso que ocurrirán durante el
desarrollo del sistema. Crea por tanto una estructura orientada al
rendimiento, usabilidad y modificabilidad (\textbf{requisitos de calidad}).
\section{Requerimientos}
\label{sec:arquitectura:requerimientos}
Objetivos de negocio\textrightarrow Drivers arquitectónicos
\textrightarrow Decisiones arquitectura\textrightarrow\\ Arquitectura
documentada\textrightarrow Riesgos Deudas
\\\par
Un requerimiento es una \textbf{especificación} que describe alguna
funcionalidad, atributo o factor de calidad de un sistema software.
\\\par
Requerimiento\textrightarrow Diseño\textrightarrow Documentación
\textrightarrow Evaluación\textrightarrow Implementación
Existe una amalgama de intereses y requerimientos entre los distintos
actores que usarán el sistema. Si bien todos juegan un papel
fundamental, a nivel de equipo de desarrollo se deberán satisfacer los
requerimientos funcionales, es decir, usar una \emph{combobox} para
elegir los billetes.\cite[p.~14]{IS1ArquitecturaDia1}
La \textbf{ISO 9126} ofrece una descripción de los criterios de
calidad del software (sección \ref{sec:cv}):\index{ISO
9126}\index{criterios de calidad}
\begin{itemize}[noitemsep]
\item Funcionalidad.
\item Confiabilidad.
\item Usabilidad.
\item Eficiencia.
\item Mantenibilidad.
\item Portabilidad.
\end{itemize}
Los \textbf{drivers} son un subconjunto de requerimientos que definen
la estructura de un sistema. Existen los drivers \textbf{funcionales},
\textbf{de atributos de alta calidad}, y los drivers de
\textbf{restricciones}.\index{drivers}
\begin{description}
\item[Funcionales] Descomposición del sistema. Relevancia y
complejidad.
\item[Calidad] Los atributos de calidad.
\item[Restricciones] Técnicas y de gestión.
\end{description}
\label{sec:drivers}
\subsubsection{Métodos para identificar drivers arquitectónicos}
\label{sec:drivers}
Existen diferentes métodos para identificar drivers
arquitectónicos. Podemos basarnos en \emph{talleres de atributos},
métodos de diseño o \emph{FURPS}\index{FURPS}\index{talleres de
atributos}\footnote{Preguntado en el examen de 2017. Método que
tiene en cuenta la usabilidad}(\emph{Functionality, Usability, Reliability, Performance, Supportability}).
El propósito de los talleres de atributos es ayudar a elegir la
arquitectura adecuada para un sistema de Software. El modelo
\emph{QAW} (Talleres de calidad del Atributo) se centra en los
requisitos del cliente, y no hace necesaria la existencia previa de
una arquitectura software.\index{QAW}
\section{Diseño de estructuras}
\label{sec:arquitectura:diseñoestructura}
El diseño es la especificación de un \textbf{objeto}, creado por algún
\textbf{agente}, que busca alcanzar ciertos \textbf{objetivos}, en un
\textbf{entorno} particular, usando un conjunto de
\textbf{componentes} básicos, satisfaciendo una serie de
\textbf{requerimientos} y sujetándose a determinadas
\textbf{restricciones}.
\begin{center}
\textit{Teniendo en cuenta lo que nos han pedido, juntar piezas que
tenemos teniendo en cuenta nuestras restricciones para describir lo que queremos
hacer.}
Arquitectura\textrightarrow Interfaces\textrightarrow Detalle de los módulos
\end{center}
Se diseña en base a los principios de \textbf{modularidad},
\textbf{alta cohesión y bajo acoplamiento} y de \textbf{mantener las
cosas simples}.
Los patrones de diseño juegan un papel fundamental en la especificación
de los drivers.\index{patrones de diseño} Se abstraen problemas ya
resueltos sin llegar a representar soluciones detalladas para luego
adaptarlo a cada caso particular. Cuando los diseños son más
concretos, se llegan a crear elementos software reutilizables que
proporcionan la funcionalidad genérica enfocándose a la resolución de
un problema específico. Así nacen los \textbf{frameworks}\index{framework}.
A la hora de diseñan las \textbf{interfaces} se identifican los
mensajes que se intercambian.\index{interfaces}
\section{Diseño de Arquitecturas}
\label{sec:arquitectura:diseñoarquitectura}
El problema del diseño de la arquitectura se resuelve mediante diseños
\textbf{basados en atributos}, \textbf{centrados en arquitectura} o con
\textbf{vistas y perspectivas}. El método de \textbf{Rozansky \&
Woods}.\index{ADD}\index{ACDM}\index{Rozansky \& Woods}
\begin{figure}[h]
\centering
\begin{tabular}[h]{p{2.5cm} || p{3cm} | p{3cm} | p{5cm}}
&\textbf{ADD}&\textbf{ACDM}&\textbf{Rozansky \& Woods} \\ \hline
Mecánica y enfoque & Diseño iterativo descomponiendo elementos
recursivamente. & Iteraciones de diseño,
documentación y
evaluación. & Iteraciones de diseño,
documentación y
evaluación. \\\hline
Participantes & Arquitecto & Arquitecto y otros & Arquitecto y
otros \\\hline
Entradas & Drivers & Drivers y alcance & Vistas \\\hline
Salidas & Esbozos de vistas & Vistas & Vistas \\\hline
Criterios de terminación & Se satisfacen los drivers & Los
experimentos
no revelan
riesgos o
son
aceptables
& Los interesados están de acuerdo en
que el diseño satisface sus
preocupaciones. \\\hline
Conceptos de diseño utilizados & Técnicas y patrones & Estilos
arquitectónicos,
patrones y
prácticas &
Estilos
arquitectónicos
y patrones.
\end{tabular}
\caption[Comparación diseño arquitecturas]{Comparación de métodos de
diseño de arquitecturas.}
Interesante ver la figura \ref{fig:costemetodologia}
\label{fig:comparaciondiseñoarquitectura}
\end{figure}
\section{Documentación}
\label{sec:documentacion}
\begin{center}
\textit{Generación de documentos que describen las estructuras de la
arquitectura con el propósito de comunicar efectivamente a los
interesados en el sistema.}
\end{center}
La documentación se apoya en vistas para la descripción de las
estructuras. Se componen de un diagrama que representa los objetos de
la estructura y de información textual que ayuda a comprender el
diagrama.
\index{vista lógica}La \textbf{vista lógica} representa en el diagrama
\emph{unidades} de implementación, que pueden ser en base a la
funcionalidad o la responsabilidad.
Otras \emph{vistas} son las de \textbf{comportamiento}, las \textbf{físicas}
o la de Windows\texttrademark~\footnote{Que no nos gusta.}.
\section{Evaluación}
\label{sec:arquitectura:evaluacion}
\begin{center}
\textit{La evaluación es la técnica para evitar que los defectos lleguen a
los usuarios finales o que se presenten en momentos donde
corregirlos sea complicado.}
\end{center}
La evaluación sirve para determinar si el software cumple con los
criterios de calidad (\ref{sec:software}). Al evaluar un sistema se
pueden producir \emph{desviaciones} respecto a las necesidades de los
usuarios o respecto a la construcción correcta del producto. Al
evaluar las arquitecturas se busca satisfacer los drivers
arquitectónicos (\ref{sec:drivers}).
\section{Implementación}
\label{sec:implementacion}
La implementación busca generar diseños detallados de los módulos y
otros elementos siempre de acuerdo con la arquitectura. Se ajustan los
diseños y errores, pero no se cambia la arquitectura.
\begin{itemize}[noitemsep]
\item Diseñar la estructura del sistema basándose en la arquitectura.
\item Basarse en los requisitos funcionales (\ref{sec:drivers}).
\item Desarrollar\footnote{Picar código y fixes.}.
\end{itemize}
La resolución de las desviaciones (\emph{errores}) se resuelve
mediante controles de calidad en los que se \textbf{verifica el
código}, el \textbf{diseño}. Además de realizar \textbf{pruebas} y
\textbf{auditorías}.
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "IS1apuntes"
%%% End:
% LocalWords: usabilidad modificabilidad combobox Confiabilidad QAW
% LocalWords: FURPS Functionality Usability Reliability Performance
% LocalWords: Supportability frameworks framework Rozansky Woods ADD
% LocalWords: ACDM Windows fixes