• No se han encontrado resultados

R I T. Software Engineering. Architectural Design: Designing before Design. Buenos Aires, Argentina Junio de 2006

N/A
N/A
Protected

Academic year: 2021

Share "R I T. Software Engineering. Architectural Design: Designing before Design. Buenos Aires, Argentina Junio de 2006"

Copied!
28
0
0

Texto completo

(1)

R I T

Software Engineering

Dr. J. Fernando Naveda

Department of Software Engineering

Rochester Institute of Technology

Rochester New York, USA

Architectural Design: Designing before Design

(2)

R I T

Agenda

9 Una corta historia del software

9 ¿Por que arquitecturas?

9 “Stakeholders”

9 Dependencias y calidad

9 Líneas de producto

9 Arquitecturas en pre-grado y post-grado

9 Conclusiones

(3)

R I T

Reconocimiento

9Partes de esta charla están basadas en el libro

Software Architecture in Practice (2

nd

Ed.) by L.

Bass, P. Clements, and R. Kazman.

(4)

R I T

Una corta historia del software

1 of 6

¡El plan es que

ustedes

comiencen a

escribir el

programa mientras

yo voy a averiguar

se que se trata!

¡Okay!

(5)

R I T

Una corta historia del software

¡Necesitamos

estándares de

programación

!

Quien

escribió

este

programa???!!!

(6)

R I T

Una corta historia del software

3 of 6

¡Necesitamos

abstract data

types

!

Quien

organizó

esta

información???!!!

(7)

R I T

Una corta historia del software

4 of 6

3 of 6

¡Necesitamos

objetos

!

Quien

organiz

ó

este

sistema???!!!

(8)

R I T

Una corta historia del software

9 Abstracción

9 Encapsulación de

información y función

9 Diseño de la interfase

9 Re-uso

9 Nos permiten documentar

las ideas que funcionan (o

no)

5 of 6

¡Nos

gustan los

(9)

R I T

Una corta historia del software

6 of 6

¡Necesitamos

patrones de

diseño

!

Pueden uds.

diseñar

sistemas

!!!???

(10)

R I T

Una corta historia del software

¡Nos gustan los

patrones de

diseño!

9 Facilitan el re-uso y

comunicación de ideas de

diseño que funcionan

9 Facilitan la decisión de

escoger el diseño mas

adecuado

9 No tenemos que adivinar

9 Previenen la re-invención

de lo que ya se ha

inventado

(11)

R I T

Una corta historia del software

¡Ustedes no pueden

hacer nada bien!

¡Necesitamos

diseños

arquitectónicos

!

(12)

R I T

De lo concreto a lo abstracto

9 Prácticas de programación

9 Lenguajes de programación

• ADTs (Información)

• Función

9 Lenguajes de programación

• Orientados a objetos

• Orientados a aspectos

9 Práctica del diseño

• Patrones de diseño

9 Diseños arquitectónicos

(13)

R I T

¿Por que arquitecturas?

9Sistemas software son cada día mas complejos

9Buenos diseños son difíciles de producir

• ¿Por que tenemos que inventar y

re-analizar diseños?

• Requieren una inversión fuerte de recursos

(14)

R I T

Diseño arquitectónico

9Concierne con al estructura de sistemas software

suficientemente grandes

9La perspectiva de la arquitectura es abstracta:

• Detalles de la implementación no son

importantes

• Detalles algorítmicos no son importantes

• Representación de la información se concentra

en el comportamiento y la interacción entre los

componentes

(15)

R I T

“Stakeholders” y prioridades

Costo y tiempo de

lanzamiento al

mercado

Usabilidad y

rendimiento

Mantenibilidad

Tendencias

técnicas

(16)

R I T

Conflictos

Tiempo al

mercado

Mantenibilidad

Usabilidad

Rendimiento

Costo

Tendencias

técnicas

Confiabilidad

Adaptabilidad

Seguridad

(17)

R I T

Dependencias

9Modificabilidad (modifiability)

• Como se dividen las funciones del sistema

entre sus componentes (arquitectural)

• Selección de algoritmos y técnicas de

programación (no-arquitectural)

9Usabilidad (usability)

• Selección de artefactos de la interacción con

el usuario (no-arquitectural)

• Habilidad del usuario de cancelar o deshacer

(18)

R I T

Arquitectura y calidad del sistema

9Hablar de arquitecturas es hablar de los

atributos cualitativos del sistema

• Disponibilidad (Availability)

• Seguridad (Security)

• Modificabilidad (Modifiability)

• Rendimiento (Performance)

• Habilidad de conducir pruebas (Testability)

• Usabilidad (Usability)

(19)

R I T

Arquitecturas y calidad del negocio

9Hablar de arquitecturas es hablar del aspecto

cualitativo del negocio de producir software

• Tiempo de lanzamiento al mercado

• Costo y beneficio

• Vida proyectada del sistema

• Mercado

• Calendario de lanzamiento

• Integración con sistemas ya existentes

• Etc.

(20)

R I T

Calidad de la arquitectura

9Integridad conceptual

9Correcto y completo

9Constructibilidad (Buildability)

La integridad conceptual del sistema es la

consideración mas importante durante la etapa

del diseño.

(21)

R I T

¿Entonces que paso?

¿Como

medimos la

calidad?

“Algo que no se puede medir,

no se puede mejorar”

(22)

R I T

Midiendo mantenibilidad

9Fuerza de interacción entre módulos

• ¿Hay módulos que dependen mucho de

otros?

9Integridad conceptual de los módulos

• ¿Cada modulo captura un concepto de

diseño único?

9Probabilidad de cambios específicos

(23)

R I T

La calidad se inyecta al sistema

9Calidad no es algo que es simplemente

agregado en algún momento dado

• Es inyectada (o no) a medida que el producto

se desarrolla

9Decisiones tácticas se deben tomar a través del

ciclo de desarrollo

(24)

R I T

Líneas de producto

9 La arquitectura del sistema

representa una inversión

significativa

9 Re-usar la arquitectura

puede ayudar a la

organización:

• Incremento de ingresos

• Reducción de costos de

producción

• Incremento de oferta de

productos

• Incremento de n

úmero

de clientes

¡Ja, Ja, Ja! Y la

competencia ni

(25)

R I T

Manéjese con cuidado

9No hay tal cosa como la arquitectura perfecta

9La arquitectura esta íntimamente ligada al

aspecto de negocios y a los requerimientos de

los “stakeholders”

9El arquitecto debe aprender a balancear los

requerimientos del sistema contra las metas y

recursos de la organización

(26)

R I T

¿Donde enseñar arquitecturas?

9A nivel de graduados

• El libro completo de Bass, Clements y

Kazman en un semestre

• Un curso exclusivo de líneas de producto

9A nivel de pre-grado

• En la parte alta del programa

• No es posible cubrir el libro completo

• Líneas de producto: Solo una introducción

• Uso de viejos proyectos como malos

ejemplos

(27)

R I T

Conclusiones

9 Hemos caminado un largo

trecho desde enfocarnos

en lo concreto a identificar

el valor de la arquitectura

de los sistemas software

9 Desarrollar la arquitectura

vale la pena si el sistema

es suficientemente grande

y se espera una vida útil

suficientemente larga

9 Es importante enseñar este

(28)

R I T

Referencias

Documento similar

Para garantizar una detección estable se escogió una cantidad de material, para cada blanco, lo suficientemente grande como para ser medida (con concentraciones muy pequeñas la señal

Este documento destaca nuestra visión colectiva sobre la Transición Energética Justa, tal como debatieron las/os participantes y se expresó en los seminarios virtuales de Amigos de

Fundada en 1573, es la capital de la provincia, ciudad más poblada después de Buenos Aires y la más extensa de Argentina. En consecuencia es un importante centro

La consecución de un número suficientemente grande de reacciones de fusión, como para que se produzca energía de manera eficiente (es decir, que se libere más energía que la que

Es aquello que una persona se traza con el fin de conseguir uno o varios propósitos para su existencia, se asocia al concepto de autorrealización, que define conscientemente

1. LAS GARANTÍAS CONSTITUCIONALES.—2. C) La reforma constitucional de 1994. D) Las tres etapas del amparo argentino. F) Las vías previas al amparo. H) La acción es judicial en

Esto puede resultar útil cuando la interfaz de la clase de servicio se cambia o sustituye, ya que puedes crear una nueva clase adaptadora sin cambiar el códi- go cliente..

In summary, the achievement is measured through a single summative assessment – a report that brings together a number of UML diagrams (types being chosen by