DS - Arquitectura de Sistemas 2012 V1

Diseo de Sistemas
Materia integradora
3 nivel

Comisin 3k2
Universidad Tecnolgica Nacional
Facultad Regional Tucumn
Ingeniera en Sistemas de Informacin
Mg. Ing. Mabel Torres
Bibliografa
Ingeniera del Software 7
ma
Ed.
Autor : Ian Sommerville
Cap. 4 Procesos del software (Apartado 4.3.2)
Cap. 11 Diseo arquitectnico

Agenda
Organizacin del Sistema Arquitectura del sistema
Tema: Desarrollo de sub sistemas
Introduccin al tema desde los procesos de la
Ingeniera en Sistemas
Importancia del diseo de la arquitectura
Criterios que guan el desarrollo de la
arquitectura
Arquitectura de la comunicacin entre sub
sistemas
Arquitectura del control de los sub sistemas
Arquitectura de los mdulos
UML - Diagrama de despliegue

11/06/2012
Agenda
arquitectura
sistemas

11/06/2012
Procesos de la Ingeniera en Sistemas
Definicin de
Requerimientos()
Diseo de
Sistema()
Desarrollo de
Subsistemas()
Integracin
del
subsistema()
Instalacin del
Sistema()
Evolucin del
Sistema()
Desmantelamiento
del sistema()
Ingeniera del
Software
Actividades de
desarrollo

Especificacin

Desarrollo

Validacin

Evolucin
Actividades bsicas del proceso de
desarrollo del software
Actividades bsicas del proceso
Se produce el software que cumpla con su
especificacin

Diseo

Implementacin Codificacin

prueba de los programas
Actividades del Diseo
El diseo de software es una descripcin de la estructura del
software que se va a implementar, los datos que son parte del
sistema, las interfaces entre los componentes del sistema y algunas
veces los algoritmos utilizados

El diseo se desarrolla de manera iterativa a travs de versiones





Los subsistemas que forman el sistema y
sus relaciones se identifican y se documentan
Requerimientos no funcionales
recordamos qu es un sub sistema ?
Un sub-sistema es una descomposicin abstracta de un
sistema. Cada sub-sistema puede a su vez ser un sistema

Pueden modelarse como un conjunto de componentes y
las relaciones entre estos componentes

Se realiza un modelo del sistema llamado Diagrama de
bloques UML diagrama de paquetes

El modelo muestra una visin general de la organizacin
del sistema: arquitectura del sistema UML diagrama de
despliegue

La organizacin del sistema depende de la perspectiva de
la aplicacin se desarrollar
Agenda
arquitectura
sistemas

11/06/2012
Disear explcitamente y documentar la arquitectura del
sistema es importante por las siguientes ventajas:

Comunicacin con las personas interesadas en el sistema
(Stakeholders): La arquitectura representa el sistema y puede
usarse como un punto de discusin

Anlisis del sistema: Las decisiones del diseo arquitectnico
tienen un gran efecto sobre si se pueden cumplir los
requerimientos no funcionales ( rendimiento, fiabilidad,
mantenibilidad) y los requerimientos funcionales

Reutilizacin a gran escala: La arquitectura es a menudo la
misma para sistemas con requerimientos similares, y por lo tanto
puede soportar reutilizacin

Agenda
arquitectura
sistemas

11/06/2012
Criterios que guan el diseo arquitectnico
Durante el proceso de diseo de la arquitectura se debe
tomar varias decisiones fundamentales que afectan
profundamente al sistema y a su proceso de desarrollo.

Encontrar las respuestas a preguntas nos ayudan a
encontrar la arquitectura que satisfaga los Requerimientos
Funcionales y los Requerimientos no Funcionales

Cmo se comunicarn los sub sistemas?
Cmo se controlar la ejecucin del los sub
sistemas?
Cmo sern los mdulos de los sub sistemas?

Comunicacin entre los sub - sistemas
Los sub sistemas se comunican entre s para intercambiar informacin
Control de los sub - sistemas
Los sub sistemas se deben controlar para que sus servicios se
entreguen en el lugar correcto y en el momento preciso
Control 1 Control 2
Control 1 Control 2
Los sub sistemas se descomponen en mdulos . Los mdulos se
componen de varios componentes ms simples del sistema
Control 1 Control 2
Mdulos de los sub - sistemas
Control 1 Control 2
Resumen de las preguntas que guan el
diseo arquitectnico
Agenda
arquitectura
sistemas

11/06/2012
Modelo de repositorio
En el centro de la arquitectura se encuentra el almacn de datos,
representado por una Base de Datos compartida

Los subsistemas no necesitan conocer cmo los otros subsistemas
utilizan los datos

Todos los subsistemas comparten el mismo esquema de datos y
realizan operaciones CRUD sobre la Base de Datos
Es eficiente para compartir gran cantidad de datos
Se centralizan las polticas de seguridad, proteccin, control de acceso
y recuperacin de errores
Promueve la capacidad de integracin
Los sub sistemas que producen datos no necesitan conocer cmo
se utilizan sus datos los otros sub sistemas
Ventajas
Puede ser difcil integrar otros subsistemas si sus modelos de datos no
se ajustan al esquema acordado (rendimiento)
La evolucin es difcil a medida que se genera gran volumen de datos
de acuerdo con el modelo de datos establecido
Impone las mismas polticas para todos los subsistemas
Puede haber problemas con la redundancia de datos y las
inconsistencias
Desventajas
Modelo Cliente - Servidor
Componentes del modelo:

Procesos servidores: ofrecen los servicios a otros subsistemas
Procesos clientes: Invocan los servicios ofrecidos y pueden tener
varias instancias del proceso ejecutndose
Red: permite la interconexin para acceder a otros servicios
Modelo Cliente - Servidor
Al ser una arquitectura distribuida hace ms efectiva el uso de sistemas en
red
Se puede agregar fcilmente procesos servidores o procesos clientes
Los subsistemas pueden organizar sus modelos de datos en forma diferente
Existen otras variaciones de este modelo
El uso de cdigo mvil
Necesidades de los usuarios
Dispositivos mviles
Ventajas
Modelo por capas
Interfaz de usuario
Comunicaciones del usuario
Recuperacin y modificacin
de informacin
Base de datos de gestin de
transacciones
Cada capa proporciona un
conjunto de servicios
Soporta el desarrollo
incremental
Es portable y soporta bien los
cambios
Ventajas
Modelo por capas
Interfaz de usuario
Comunicaciones del usuario
Recuperacin y modificacin
de informacin
Base de datos de gestin de
transacciones
La estructuracin del sistema
puede ser difcil
Para tener acceso a los
servicios requeridos, una capa
puede tener que comunicarse
con los niveles inferiores
El rendimiento puede ser un
problema
Desventajas
Modelo por capas
Larman
Modelo por capas
Larman
Ventanas de la GUI Informes
o reportes impresos
Funciones del dominio de
aplicacin Ej. Ventas,
Inventarios
Servicios tcnicos
Persistencia - Seguridad
Estructura fsica de la Base de
Datos
G.U.I
Base de
Datos
Modelo por capas
Larman
Lnea de dependencia

La lnea de dependencia entre
paquetes indica que los elementos del
paquete dependiente conocen o estn
acoplados de algn modo con los
elementos del paquete destino
Arquitectura en capas
Diagrama de paquetes
Base de
Datos
La ausencia de dependencia de un
paquete con el paquete otro
significa que los componentes del
primer paquete no tienen
referencias a ninguna clase,
componentes, interfaz, mtodo o
servicios del otro
G.U.I
Agenda
arquitectura
sistemas

11/06/2012
Control 1 Control 2
Modelo orientado a objetos
Los mdulos son objetos con estados y operaciones definidas para
esos estados
Los objetos realizan llamadas a servicios proporcionados por otros
objetos
Los objetos estn dbilmente acoplados por lo tanto la implementacin
modifica poco otros objetos
Modelo orientado flujos de funciones
Los datos fluyen de una funcin a otra y se van transformando
Objetos y Clases
Un objeto es una entidad que tiene un estado y un
conjunto de operaciones definidas que operan sobre ese
estado
El estado se representa como un conjunto de atributos
del objeto
Las operaciones asociadas al objeto proveen servicios
a otros objetos clientes que solicitan estos servicios
cundo se requiere llevar a cabo algn clculo

Los objetos se crean conforme a una definicin de
clases de objetos
Una clase sirve como una plantilla para crear objetos
La clase incluye las declaraciones de todos los atributos
y operaciones asociadas con un objeto de esa clases

Una clase en UML
Empleado
nombre:string
domicilio:string
fechaDeNacimiento: date
estado:{retirado,activo,des
pedido}

IngresoALaEmpresa()
AbandonarLaEmpresa()
retiroDeLaEmpresa()
modificarInformacion
Nombre de la clase- Siempre
comienza con mayscula
Atributos de la clase Siempre
comienzan con minscula
Operaciones
Identificacin de objetos y clases
Mdulos del sistema
En esta etapa del proceso de diseo, se debe utilizar el
conocimiento del dominio de la aplicacin para identificar los objetos
y servicios del sistema
El modelo del dominio muestra las clases conceptuales
significativas del dominio de inters
Propuestas para identificar las clases
Anlisis gramatical de la descripcin del sistema (Documentacin de
los Casos de Usos). Los sustantivos son objetos y atributos, los verbos
son operaciones o servicios
Lista de categoras: entidades tangibles o fsicos, lugares,
transacciones, roles de la gente, reglas y polticas, organizaciones,
catlogos
Enfoque de comportamiento: se comprende el comportamiento total
del sistema. Se comprende quien inicia y participa en los
comportamientos
Anlisis basado en escenarios se identifican y analizan varios
escenarios de la forma de utilizar el sistema. De cada escenario se
identifican objetos, atributos y operaciones

Agenda
arquitectura
sistemas

11/06/2012
Control 1 Control 2
Modelo de llamada - retorno
Un sub sistema se disea como el controlador del sistema y gestiona
la ejecucin de los otros sub sistemas
Las decisiones de control se determinan por los valores de las
variables de estado del sistema

El control comienza al inicio de la jerarqua
A travs de llamadas, el control pasa a niveles inferiores
Control centralizado
Sistema secuencial
Llamada - retorno
Modelo de llamada - retorno
Es relativamente simple de analizar los flujos de control y
conocer cmo responder el sistema a ciertos tipos de
entradas
Las excepciones a las operaciones normales son difciles
de manejar
Ventajas
Sistema secuencial
Control 1 Control 2
Modelo del gestor
Un componente del sistema se disea como gestor del
sistema
Controla el inicio, parada y coordinacin del resto de los
procesos (sub sistema)
Tambin se puede aplicar a sistemas secuenciales
Sistema concurrente
Control 1 Control 2
Modelo de transmisin
Se rigen por eventos generados externamente
Los eventos estn bajo el control del ambiente o entorno del sistema

El control est embebido en el manejador de eventos y mensajes
Los sub sistemas registran inters en los eventos
Los sub sistemas indican que algn dato est disponible
Dirigido por eventos
Los sub sistemas no conocen si los eventos se manejarn ni cundo
sern manejados
Cuando un sub sistema genera un evento no conoce qu sub-
sistema ha registrado un inters en dicho evento
El control est embebido en el manejador de eventos y mensajes
Desventajas
Control 1 Control 2
Modelo dirigido por interrupciones
Se usan en sistemas de tiempo real en los que es necesaria una
respuesta inmediata a algn evento
Hay varios tipos de interrupciones. Cada interrupcin se asocia a su
manejador
Permite implementar respuestas muy rpidas a eventos

Notacin general de los diagrama de
interaccin
Venta :Venta v1:Venta
Clase
Instancia
Instancia nombrada
Para mostrar una instancia de una clase en un diagrama de
interaccin, se utiliza el smbolo grfico para una clase, un
rectngulo con el nombre subrayado

Se puede utilizar un nombre para identificar de manera nica a
la instancia
interaccin
Un enlace es un camino de conexin entre 2 objetos:Indica que
existe algn grado de visibilidad y navegacin entre los objetos
enlazados

Un enlace es una instancia de asociacin

Pueden fluir varios mensajes a travs del mismo enlace

Lnea de enlace
Enlaces
interaccin
Los mensajes entre los objetos se representan con una
expresin de mensaje y una pequea flecha que indica la
direccin del mensaje
Pueden fluir varios mensajes a travs de una lnea de enlace
Se numeran para poder seguir la secuencia
Se puede colocar mensajes a si mismo

Mensajes
Mensajes
Fin de la presentacin

DS - Arquitectura de Sistemas 2012 V1

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

DS - Arquitectura de Sistemas 2012 V1

Cargado por

Copyright:

Formatos disponibles

Diseo de Sistemas

También podría gustarte