Dis S 04 Analisis y Diseño 2011 I

Universidad de San Martín de Porres
Facultad de Ingeniería y Arquitectura
Diseño e Implementación de Sistemas
Análisis y Diseño
Sesión: 04
Mg. Géner Zambrano L.
gzambranol@usmp.pe
Semestre: 2011_I
Objetivos
• Conceptos de arquitectura de software y
su importancia
• Definiciones de calidades sistémicas
• El rol del arquitecto
• Arquitectura en Procesos de Desarrollo
• Arquitectura y diseño de aplicaciones J2EE

Un Modelo para procesos de
Ingeniería de SW
Disciplinas y Enfoque Iterativo de
RUP
Diseño de Software
• Después de comprender los requerimientos, el diseño es el

MAPA de cómo construir el sistema
• Un principio de diseño es un lineamiento de diseño
comúnmente aceptado que cuando se aplica resulta en
características específicas de diseño
• Un paradigma de diseño representa un conjunto de principios
de diseño complementarios que colectivamente se aplican
para soportar objetivos comunes
• Un patrón de diseño identifica un problema común y
proporciona una solución recomendada
• Un estándar de diseño es una convención interna y específica
para una organización, para regir sus diseños
Paradigmas de Diseño
Design Results in the Design

Paradigm Creaton of specific Characteristics Design
Paradigm
A r by a tio
e c th n o
ap
Is comprised of
re a e
p li
multiple
c
t ed
Contribute to
f
Support the Design Result in the

Realization of Principles Creation of specific the successful
realization of
e
h de Ca
rtt r iv n
po o f ed b e
u p se fr
S u om
Design
Best Practices
Support the
Design Standards
Design Standards Best Practices
use of Patterns
Paradigmas de Diseño, continua...
10100001111101010101
• Bajo Nivel (Binario)
– Tarjetas perforadas
• Bajo Nivel (Ensamblador)

– Mnemónicos para
funciones
– Direcciones de
memoria con etiquetas
Lenguajes Procedurales Ejemplo:

• Uso de vocabulario
relativo al problema en
resolución
• Describen paso-a-paso el
procedimiento exacto
para resolver un
problema.
• La realidad debe
modelarse con base en
las capacidades del
lenguaje.
• Difícil de comprender
para no-programadores.
Lenguajes Orientados a Objetos Ejemplo:

• Los datos y los métodos para
manipularlos se encapsulan en
una unidad conceptual llamada
objeto.
• Permiten modelar la realidad,
adaptando el código a la misma.
• La sintaxis es muy natural y
comprensible incluso para no
programadores.
• Grandes capacidades de reuso de
código, agilidad para desarrollar
y aplicar cambios.
• JAVA, .NET, etc
Arquitectura de Software
¿Qué es una arquitectura?
“No estamos seguros, pero la reconocemos cuando vemos

una”
Arquitectura de Software, continua...
• IEEE 1471 • Software Architecture in

El nivel conceptual más alto de Practice – Kazman
un sistema en su ambiente.
“La estructura de estructuras
de un sistema, la cual abarca
• “Arquitectura es la organización componentes de software,
fundamental de un sistema propiedades externas visibles
descrita en: de estos componentes y sus
– Sus componentes. relaciones”.
– Relación entre ellos y con el
ambiente. • “El objetivo de esta definición
es que la arquitectura de
– Principios que guían su software debe abstraer alguna
diseño y evolución”. información del sistema y aún
proveer suficiente información
para ser la base del análisis,
toma de decisiones y lograr la
reducción de riesgos”.
• Rational Unified Process • SUN SL-425: Architecting

and Designing J2EE
“Arquitectura es la Applications
estructura de los
componentes más “Arquitectura se refiere a la
significativos de un sistema representación abstracta de los
componentes de un sistema y
interactuando a través de
su comportamiento”.
interfaces con otros
componentes conformados “La arquitectura no contiene
por componentes detalles de implementación”.
sucesivamente pequeños e
interfaces”.
¿Qué es un Proceso de Arquitectura?
Rational Unified Process:
• Secuencia de actividades que conllevan a la producción

de artefactos arquitectónicos:
– Descripción de arquitectura
– Prototipo arquitectónico
¿Por qué es importante definir una
arquitectura?
Premisa:
• Las arquitecturas de los sistemas, existen indiferente si han sido
definidas formalmente o no.
• Dos factores primarios en la ingeniería de software que han

incrementado la importancia de la arquitectura:
Evolución de las arquitecturas
Aplicaciones Monolíticas Arquitectura Cliente-Servidor
• Interfaces gráficas de usuario • Clientes pesados, no estándar

(GUI). • Conexiones dedicadas a BD
• Protocolos pesados
• Servicios de presentación, • Ejecución remota de SQLs
negocios y persistencia en la
misma máquina. • Alta administración
• Bajo rendimiento
• No hay concurrencia de • Alto tráfico de red
usuarios. • Baja accesibilidad
• Alto acoplamiento entre tiers.
• Presentación
• Lógica negocio • Presentación
• Persistencia • Lógica de negocio • Persistencia
Evolución de las arquitecturas, continua...
Arquitectura Cliente-Servidor Aplicaciones 3 niveles

Mejorada
• Reutilización de lógica de negocio
• Clientes pesados, no estándar. para diferentes clientes o sistemas.
• Conexiones dedicadas a la BD. • Mejora la escalabilidad.
• Lógica de negocios en BD
• Mejora en rendimiento • Mejora la flexibilidad.
• Alta administración • Independencia de la base de datos.
• Baja escalabilidad
• Baja flexibilidad Clientes GUI Servidor de
• Baja portabilidad Base de
semi-livianos Aplicaciones
Datos
Presentación
Clientes GUI Procedimientos Negocio
Semilivianos Almacenados (EJB, CORBA, COM+)
Aplicaciones N-niveles (clientes livianos)

Clientes Web Servidor de Database
livianos Server Aplicaciones Servers
100.000+
Lógica de
Despliegue de Presentación negocios
contenido
• Bajo costo de administración de clientes.

• Alta accesibilidad.
• Alta flexibilidad.
• Alta disponibilidad y tolerancia a fallos.
• Alta escalabilidad.
• Independencia de DB
• Situación actual de Sistemas

Empresariales
• Las empresas necesitan agilidad

en su negocio:
– Requerimientos cambian
continuamente.
– Implementación de nuevos
programas o servicios para
atraer o retener clientes.
– Requieren unificar, refina y
medir sus procesos de
negocio
• Requieren que su infraestructura

de IT se pueda adaptar al
cambio, se flexible y tener
libertad de escoger nuevas
tecnologías o productos en una
relación costo beneficio.
Procesos fragmentados
• Aplicaciones publicadas en
diferentes departamentos y
unidades de negocios
•Como se pueden integrar procesos y datos en una empresa

con una relación costo beneficio efectiva?
•Como ayuda la arquitectura de software?

Visión idealizada de Arquitectura Orientada a Servicios (SOA)
Portal de
Servicios Integrados
Sistema
Batch Cluster de
Servidores de
Aplicaciones
Requerimientos
Arquitectónicos Base de
Datos
• Heterogeneidad Servidor de
• Escalabilidad Procesos
• Disponibilidad (BPM) Aplicaciones
Legadas
• Distribución
• Manejabilidad de Procesos
• Administración y monitoreo de procesos,
servicios e infraestructura
¿Qué es un Arquitecto de Software?
• Rational Unified Process • SUN SL-425:
Arquitecto es un rol en un
proyecto de desarrollo de El arquitecto:
software el cual tiene las – Visualiza el comportamiento
siguientes responsabilidades: del sistema.
– Crea los planos del sistema.
– Liderar el proceso de
arquitectura. – Define la forma en la cual los
elementos del sistema
– Producir los artefactos trabajan en conjunto.
necesarios: Documento
de descripción de – Responsable de integrar los
arquitectura requerimientos no-funcionales
(NRFs) en el sistema.
– Modelos y prototipos de
arquitectura.
Arquitectura vs. Diseño
Arquitectura Diseño
Nivel de Alto nivel Bajo nivel. Enfoque

Abstracción específico en detalles
Entregables Planear subsistemas, Diseño detallado

interfaces con sistemas componentes,
externos, servicios Especificaciones de
horizontales, frameworks, codificación
componentes reutilizables,
prototipo arquitectónico
Áreas de Selección de tecnologías, Requerimientos
Enfoque Requerimientos no funcionales
funcionales (QoS),
Manejo de riesgos
Arquitectura vs. Diseño, continua…
La arquitectura envuelve un conjunto de decisiones

estratégicas de diseño, lineamientos, reglas y patrones que
restringen el diseño y la implementación de un software.
Código
Implementación
Diseño
Arquitectura
Artefactos de Arquitectura
Rational Unified Process:
En el proceso de definición de arquitectura se producen:
• Arquitectura Inicial.
• Arquitectura de Referencia.
• Documento de Descripción de arquitectura (SAD):
– Subsistemas
– Componentes
– Arquitectura Runtime.
• Guías para el proyecto y

estándares de Diseño.
Evaluación de Tecnologías
• Beneficios de las habilidades del arquitecto para evaluación de
tecnologías en proyectos:
– Aceptación. Conseguir la aceptación de los participantes

del proyecto sustentando sus recomendaciones y
decisiones con un buen nivel de fundamentación.
– Uso adecuado. Asegurar el uso apropiado de las

tecnologías por los miembros del equipo.
•Un Arquitecto es un facilitador y líder.

•No toma decisiones unilaterales, irracionales.
•Evita riesgos en los proyectos, agrega valor.
Control de Riesgos, continua…
• La calidad de servicio (QoS = Quality Of Service) es un riesgo

primario relacionado con la arquitectura.
• El manejo inadecuado de los requerimientos no funcionales,

es una de las fuentes más importante de riesgo en los
proyectos:
– Reglas de negocio de alta complejidad.
– Calidades sistémicas
• Seguridad
• Rendimiento
• Escalabilidad
• Disponibilidad
• Extensibilidad
Calidades Sistémicas
Definición • Familias de Calidades
Sistémicas
• Son propiedades que
establecen la calidad de servicio • Manifiestas
(QoS) que un sistema expone. • Operacionales
• Desarrollo
• Son globales a toda la
arquitectura e influencian el • Evolutivas
diseño.
• Son no-funcionales pero

observables.
• No se pueden satisfacer
completamente por un
componente.
Calidades Sistémicas, continua…
Calidades Manifiestas:
• Observables por los usuarios del sistema.
– Performance. Tiempo de respuesta desde el punto de

vista del usuario.
– Reliability. Grado de probabilidad de realizar

operaciones correctamente.
– Availability. Porcentaje de tiempo que un sistema

puede procesar solicitudes.
Calidades Manifiestas:
Observables cuando el sistema está operando en producción:
• Throughput. Solicitudes atendidas • Security. Prevención de uso

por unidad de tiempo. indeseado, por abuso o uso
inapropiado:
• Manageability. Cantidad inversa – Identidad

de esfuerzo para realizar labores – Autoridad
administrativas. – Confidencialidad
– Auditabilidad
– Integridad
• Serviceability. Esfuerzo para
actualizar el sistema para reparar
errores. • Testability. Esfuerzo invertido para
detectar y aislar errores.
Calidades Evolutivas:
Relacionadas con el comportamiento del sistema cuando es actualizado.
• Escalability. La habilidad para • Reusability. Esfuerzo ganado en la

soportar la calidad de servicio utilización de componentes
requerida conforme la carga existentes.
aumenta.
• Portability. Esfuerzo ahorrado
• Flexibility. Esfuerzo ahorrado cuando se migra a una
cuando se hace un cambio de infraestructura diferente.
configuración.
• Mantainability. Esfuerzo ahorrado
• Extensibility. Esfuerzo ahorrado para revisar y corregir errores de
para adicionar nuevas diseño.
funcionalidades.
Recursos de Arquitectura y Diseño
Un patrón es una solución a un problema en un contexto
Un patrón codifica conocimiento específico acumulado por

la experiencia en un dominio
Un sistema bien estructurado contiene patrones: “Cada

patrón describe un problema que ocurre una y otra vez en
nuestro ambiente, y luego describe el núcleo de la solución
a ese problema, de tal manera que puedes usar esa
solución un millón de veces más, sin hacer jamás la misma
cosa dos veces.”
Christopher Alexander, 1977
Recursos de Arquitectura y Diseño, continua…
Elementos de un patrón:
Nombre
• Define un vocabulario de diseño
• Facilita abstracción
Problema
• Describe cuando aplicar el patrón MVC
• Conjunto de fuerzas: objetivos y restricciones
• Prerrequisitos
Solución
• Elementos que constituyen el diseño (template)
• Forma canónica para resolver fuerzas
Consecuencias
• Resultados, extensiones
Organización de Patrones
Propósitos:
– Identificar relaciones entre patrones
– Agrupar patrones en clusters
– Identificar patrones a diversos niveles de abstracción
– Aplicar patrones a múltiples aspectos de una solución
– Organizar patrones en un frame
– Usar patrones para describir en forma concisa una

solución…
Catálogos de Patrones
• Como arquitecto se debe familiarizar
con la mayor cantidad de patrones
posibles:
– Dedique tiempo a los catálogos

de patrones.
– Conozca los patrones que están

disponibles.
– Adquiera experiencia en el uso

de los patrones.
– Conozca como tipificar los

problemas que resuelven los
patrones.
Catálogos de Patrones
• Un arquitecto experimentado
reutiliza:
– Arquitecturas de sistemas
exitosos.
– Diseños que han funcionado

correctamente en el pasado.
– Frameworks conceptuales y
tecnológicos.
– Componentes y librerías.
Comentario Problemas Soluciones Fase de Desarrollo
Patrones de llamadas
entre objetos (similar a
Relacionados a la Problemas arquitectónicos,
los patrones de diseño),
Patrones de interacción de objetos adaptabilidad a requerimientos
decisiones y criterios Diseño inicial
Arquitectura dentro o entre niveles cambiantes, performance,
arquitectónicos,
arquitectónicos modularidad, acoplamiento
empaquetado de
funcionalidad
Conceptos de ciencia de Claridad de diseño, Comportamiento de

Patrones de computación en general, multiplicación de clases, factoría, Clase-
Diseño detallado
Diseño independiente de adaptabilidad a requerimientos Responsabilidad-
aplicación cambiantes, etc Contrato (CRC)
Modelado del dominio,

Modelos de dominio,
completitud, integración y
Patrones de Usualmente específicos de conocimiento sobre lo
equilibrio de objetivos múltiples, Análisis
Análisis aplicación o industria que habrá de incluirse (p.
planeamiento para capacidades
ej. logging & reinicio)
adicionales comunes
Desarrollo o procesos de Armado de equipo, ciclo

Patrones de administración de de vida del software,
Productividad, comunicación
Proceso o de proyectos, o técnicas, o asignación de roles, Planeamiento
efectiva y eficiente
Organización estructuras de prescripciones de
organización comunicación
Operaciones comunes bien

Sumamente específicos Implementación,
Estándares de codificación conocidas en un nuevo ambiente,
Idiomas de un lenguaje, Mantemimiento,
y proyecto o a través de un grupo.
plataforma o ambiente Despliegue
Legibilidad, predictibilidad.
Requerimientos no funcionales
Escenarios, tácticas, frameworks
Performance
Disponibilidad
Modificabilidad
Seguridad
Verificabilidad (Testability)
Gestionabilidad (instrumentación, management,
estado)
Usabilidad
Framework
Definición de Framework
• Es un subsistema de software parcialmente construido, de

propósito general para un tipo específico de problema, el cual
debe ser instanciado para resolver un problema particular.
Características
• Define la arquitectura para una familia de subsistemas
• Provee bloques básicos de construcción y adaptadores.
Típicamente un framework se construye a partir de patrones

de diseño. Los frameworks imponen patrones de diseño para
su uso
Framework, continua…
• Ventajas: • Frameworks Caja-Negra:

– Son probados.
– Alto nivel de abstracción.
– Algunos reutilizan mejores – Problemas para identificación

y corrección de errores en
prácticas de diseño.
desarrollo y producción.
– Organizan ciertos aspectos – Mecanismos limitados de

extensibilidad.
del desarrollo de un
proyecto. – No permiten optimizaciones.
– Riesgos de compatibilidad
– Minimización de riesgos. entre versiones.
– Dependencias potenciales
con un fabricante.
Framework, continua…
Ejemplos de Frameworks:
Tecnológicos: Conceptuales:
• Struts y Java Server Faces (JSF) • Definición de arquitecturas.
para Interfaces Web.
• eTom (enhanced
• Mapeos objeto-relacionales.
Telecomunication Operations
• Enterprise Java Beans para Map), es un marco referencial
construcción de servicios de de procesos para la industria
negocios. de las telecomunicaciones.
• Framework de patrones de diseño • RUP como metodología para

para J2EE de Sun Microsystems. definición de procesos de
desarrollo.
• Framework para testing de
performance.
Métodos de Desarrollo
Principios Fundamentales de Métodos Modernos
• Desarrollo iterativo e incremental.

• Conducido por las calidades sistémicas.
• Centrado en la arquitectura.
• Dirigido por los casos de uso.
• Basada en Modelos.
• Mejores prácticas de diseño.
Desarrollo Iterativo e Incremental
• Compare el costo de hacer correcciones en un desarrollo
tradicional, con el costo de hacer correcciones en un
desarrollo iterativo.
Desarrollo Tradicional Desarrollo Iterativo
Costo fijo
Costo fijo
Tiempo Tiempo
Desarrollo Iterativo e Incremental, continua…
Riesgo
Riesgo de un
proceso en
cascada
Reducción de Riesgo
Riesgo de un
proceso iterativo
Tiempo
Desarrollo Conducido por las Calidades
Sistémicas
• Las calidades sistémicas son requerimientos no
funcionales, los cuales definen la calidad de servicio que un
sistema expone.
• Algunos ejemplos:
– Rendimiento
– Confiabilidad
– Escalabilidad
– Seguridad
• Las calidades sistémicas impactan directamente la

arquitectura de un sistema.
Desarrollo Basado en Modelos
Definición
• Los modelos son mecanismos primarios de comunicación entre todos
los participantes de un proyecto de software. Reflejan un aspecto
particular de un sistema y abstraen detalles no relevantes.
Tipos Aplicación
• Documentos de texto
• Diagramas UML
• Prototipos Negocios
Objetivos
Middleware
• Comunicación
• Resolver Problemas
• Pruebas de Concepto Sistema
Definición de Arquitectura en RUP
• Proceso de Desarrollo Unificado

Definición de Arquitectura en RUP, continua…
Fase de Inicio
• Durante la fase de inicio se
establece:
– Requerimientos no-funcionales.
– Arquitectura inicial, la cual se
considera viable para el proyecto.
– Lista de Riesgos y Restricciones.
• Entregables:
– Documento de Visión
– Arquitectura Inicial
– Plan de la siguiente fase
Fase de Elaboración
• Durante esta fase se crean:
– Arquitectura línea base.
– 80% de los requerimientos
del sistema.
– Plan de iteraciones para la
fase de construcción.
• Entregables:
– Requerimientos del Sistema.
– Documento de Definición de
Arquitectura.
– Prototipo evolutivo de
arquitectura.
– Guías y Estándares.
– Plan de Iteraciones.
Modelo de Vista 4+1

• Framework para Descripción de Arquitecturas del
Rational Unified Process (RUP), basado en vistas lógicas
y físicas UML y una vista funcional de casos de uso.
Logical View Implementation View
Analysts/Designers End-user Programmers

Structure Functionality Software management
Use-Case View
Process View Deployment View

System integrators System engineering
Performance System topology
Scalability Delivery, installation
Throughput communication
Definición de Arquitectura en SunTone AM,
continua…
• SunTone AM es una metodología de desarrollo de software análoga

al Unified Process, con un fuerte énfasis en las calidades sistémicas y
patrones de diseño.
• Tiene un framework conceptual, el cubo, el cual provee una vista

tridimensional de:
– Tiers lógicos
– Layers tecnológicos
– Calidades sistémicas
• Con el cubo se puede definir la matriz tecnológica de Layers y Tiers,

la cual documenta las decisiones tecnológicas para soportar la
arquitectura de un sistema.
Definición de Arquitectura en SunTone AM
ción s ci ón
te n ta ocio gra rso
Tiers en rese e g te e cu
C l i P N I n R
s
S
Layers S E
R
Aplicación A E C C
P V A U
L L
E A R
I A
Plataforma R I I
A B
Virtual F L T
B I
O A Y
Plataforma I L
R B
Superior L I
M I
I T
Plataforma A L
T Y
Inferior N I
Y
C T as
ic
Transporte E Y m
isté S
a d es
i d
C al
continua…
Cliente Presentación Negocios Integración Recursos
- Estabilidad +
Volatilidad
+ -
continua…
Layers Tiers

Aplicación HTML Java Servlets POJO DAO Tablas
Java Script JSPs
Plataform Servlets 2.1

a Virtual JSPs 1.1
Plataform Web Browser Apache 1.3.x, Tomcat 4.x MySQL

a Superior
Plataform Independiente Linux

a Inferior
Red HTTP JDBC
POJO: Plain Old-Style Java Object

continua…
Layers Tiers

Aplicación HTML JSPs Session DAO Tablas
Java Script ActionForms, Beans
Actions
Plataform Struts 1.x EJB 2.0

a Virtual Servlets 2.1
JSPs 1.1
Plataform Web Browser Apache 1.3.x JBOSS Oracle DB
a Superior Tomcat 4.x
Plataform Independiente Linux

a Inferior
Red HTTP RMI/IIOP JDBC

Desarrollo Centrado en la Arquitectura
4 + 1 View Model • SunTone AM agrega dos

Framework de definición de características importantes a
arquitectura del RUP RUP:
– Un enfoque en las
calidades sistémicas
– El uso de patrones basados
en el razonamiento
• Framework el Cubo:
Definición de Arquitectura en SunTone
Fundamentos
• La arquitectura es primariamente necesaria para crear un
framework para el desarrollo basado en patrones y para la
entrega de calidades sistémicas predecibles.
Presentation Business Business Database Integration

Integration
Action Factory
DAO
Business Factory Oracle DAO
Delegate Factory
Action
Session Facade Composite Entity
Front Controller
View DAO
Service Value OracleDAO
JSF Components
Locator Object
Definición de Arquitectura en Iterative
Founding Method
Definición
• Metodología con un enfoque de retorno
a la inversión (ROI) informado, en el
cual el software es desarrollado y
puesto en producción, en trozos de
funcionalidades que agregan valor al
usuario, cuidadosamente priorizados,
llamados MMFs (Minimum Marketable
Features).
• IFM integra actividades de ingeniería

de software, con estrategias
financieras de administración de
proyectos.
• Descompone la arquitectura en
elementos arquitectónicos (AEs).
Founding Method, continua…
Principios Arquitectónicos
• El proceso de creación de arquitectura, debe ser un proceso
de creación de valor.
• Descompone la arquitectura en elementos arquitectónicos
(AEs).
• Disminuye los costos de implementación de los AEs en un
modelo de secuencia.
• Crea la arquitectura de software incrementalmente acorde a
un proceso secuencial dirigido por el retorno a la inversión
(ROI).
Primer principio arquitectónico:

“Difiera la solución de cualquier conflicto arquitectónico,
hasta el momento en que la decisión sea necesaria”.
Founding Method, continua…
Definir arquitectura • La codependencia de la
candidata Arquitectura en
procesos tradicionales.
Evaluar Req.
No Funcionales (NFR)
Refinar y Seleccionar
la Arquitectura
Prototipar la
Arquitectura
Medir Calidades Ajustar

Sistémicas Arquitectura
Conclusiones y Recomendaciones
Respecto a la arquitectura de software
• La Arquitectura aborda la problemática de más alto nivel de los
proyectos, es crítica debido al alto riesgo de los proyectos actuales
por su escala, distribución y complejidad.
• La arquitectura determina la estructura general de un sistema, la
cual debe satisfacer la calidad de servicio requerida, mitigar riesgos.
• Las decisiones de arquitectura restringen el diseño y la
implementación de un proyecto.
Respecto al arquitecto
• Es un rol crítico en los proyectos, se focaliza en la calidad de servicio
y lidera el proceso de definición y la implementación de la
arquitectura.
• El arquitecto reutiliza arquitectura exitosas, frameworks y patrones
de diseño.
• No es un diseñador en un proyecto.
Conclusiones y Recomendaciones
Respecto al Proceso de Definición de Arquitectura
• El proceso de definición de arquitectura debe ser un proceso
incremental de creación de valor.
• Defina solo los entregables necesarios para definir la arquitectura
acorde a las necesidades y trace la estrategia adecuada.
Fuente:XXV Salón de Informática “Arquitecturas Empresariales de Software”

MVC
Output Vista
Modelo
Input Controlador
Model
• Encapsula los datos y reglas específicas de la aplicación

(Capa de negocio + Capa persistencia).
• Aporta:
– Métodos para el manejo de datos y servicios
– Métodos para acceder al estado del sistema.
• Mantiene registro de las diferentes vistas y cotroladores
para notificar los cambios (Modelo de eventos).
View
• Mecanismo necesario para mapear los datos

provenientes del modelo al renderizado (proceso de
generar una imagen desde un modelo usando una
aplicación) de la interfaz.
• Cuando el modelo cambia, la vista es informada.
– La vista solicita al modelo la información
– Se responsabiliza de actualizar la pantalla
• Detectar áreas defectuosas (quedan descubiertas
cuando estuvieron ocultas por otra ventana, por
ejemplo).
• Redibujar la pantalla cuando se solicite.
Controller
• Intercepta los eventos de entrada provenientes del usuario

del sistema
• Traduce los eventos en invocaciones al modelo de la
aplicación
• Activa o desactiva los elementos de la interfaz de usuario
(en el ámbito de las aplicaciones Windows, pone los
botones habilitados o en gris)
Modelos de desarrollo de aplicaciones web en Java
• Los Servlets son buenos ejecutando lógica del negocio, más
no presentando información.
• JSPs son muy buenos presentando información pero pésimos
introduciendo lógica programática en ellos.
• La combinación Servlet/JSPs es lo más común hoy en día en
el desarrollo de aplicaciones web
• Dos arquitecturas:
– Model-1: JSPs para presentación y control y JavaBeans
para la lógica
– Model-2: Model-View-Controller = JavaBeans-JSPs-
Servlets
Fuente: Apache Jakarta Struts

Arquitectura Model 1
Model-1: JSPs para presentación y control y JavaBeans para la
lógica
Arquitectura Model 2
Model-2: Model-View-Controller = JavaBeans-JSPs-Servlets
MVC es tan común que se han desarrollado varias
infraestructuras en torno a este patrón de diseño:
– Apache Struts
Como funciona en una aplicación Web
Fuente: http://www.programacion.com/articulo/manual_basico_de_struts_155
TRAZABILIDAD CON UML
Análisis Diseño
JSP
<<Build>>
Boundary
Form
JSP_Client
(from JSP) (from JSP_Client)
Análisis Diseño
C o ntrol
Análisis Diseño
Bean
Entity
ClaseDAO
Universidad de San Martín de Porres
Facultad de Ingeniería y Arquitectura
Diseño e Implementación de Sistemas
Análisis y Diseño
Fin de la sesión: 04
Mg. Géner Zambrano L.
gzambranol@usmp.pe
Semestre: 2011_I

Dis S 04 Analisis y Diseño 2011 I

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Dis S 04 Analisis y Diseño 2011 I

Transféré par

Droits d'auteur :

Formats disponibles

Universidad de San Martín de Porres

Facultad de Ingeniería y Arquitectura

Diseño e Implementación de Sistemas

Mg. Géner Zambrano L.

• Definiciones de calidades sistémicas

• El rol del arquitecto

• Arquitectura en Procesos de Desarrollo

• Arquitectura y diseño de aplicaciones J2EE

• Después de comprender los requerimientos, el diseño es el

Design Results in the Design

Support the Design Result in the

• Bajo Nivel (Ensamblador)

Lenguajes Procedurales Ejemplo:

Lenguajes Orientados a Objetos Ejemplo:

¿Qué es una arquitectura?

“No estamos seguros, pero la reconocemos cuando vemos

• IEEE 1471 • Software Architecture in

• Rational Unified Process • SUN SL-425: Architecting

¿Qué es un Proceso de Arquitectura?

Rational Unified Process:

• Secuencia de actividades que conllevan a la producción

• Dos factores primarios en la ingeniería de software que han

• Interfaces gráficas de usuario • Clientes pesados, no estándar

Arquitectura Cliente-Servidor Aplicaciones 3 niveles

Aplicaciones N-niveles (clientes livianos)

• Bajo costo de administración de clientes.

• Situación actual de Sistemas

• Las empresas necesitan agilidad

• Requieren que su infraestructura

•Como se pueden integrar procesos y datos en una empresa

•Como ayuda la arquitectura de software?

Visión idealizada de Arquitectura Orientada a Servicios (SOA)

Nivel de Alto nivel Bajo nivel. Enfoque

Entregables Planear subsistemas, Diseño detallado

La arquitectura envuelve un conjunto de decisiones

• Guías para el proyecto y

– Aceptación. Conseguir la aceptación de los participantes

– Uso adecuado. Asegurar el uso apropiado de las

•Un Arquitecto es un facilitador y líder.

• La calidad de servicio (QoS = Quality Of Service) es un riesgo

• El manejo inadecuado de los requerimientos no funcionales,

• Son no-funcionales pero

– Performance. Tiempo de respuesta desde el punto de

– Reliability. Grado de probabilidad de realizar

– Availability. Porcentaje de tiempo que un sistema

• Throughput. Solicitudes atendidas • Security. Prevención de uso

• Manageability. Cantidad inversa – Identidad

• Escalability. La habilidad para • Reusability. Esfuerzo ganado en la

 Un patrón es una solución a un problema en un contexto

 Un patrón codifica conocimiento específico acumulado por

 Un sistema bien estructurado contiene patrones: “Cada

– Agrupar patrones en clusters

– Identificar patrones a diversos niveles de abstracción

– Aplicar patrones a múltiples aspectos de una solución

– Organizar patrones en un frame

– Usar patrones para describir en forma concisa una

– Dedique tiempo a los catálogos

– Conozca los patrones que están

– Adquiera experiencia en el uso

– Conozca como tipificar los

– Diseños que han funcionado

Conceptos de ciencia de Claridad de diseño, Comportamiento de

Modelado del dominio,

Un patrón es una solución a un problema en un contexto

Un patrón codifica conocimiento específico acumulado por

Un sistema bien estructurado contiene patrones: “Cada