diseño dmuy bueno

FAVA - Formacin en Ambientes Virtuales de Aprendizaje

TTULO

SENA - Servicio Nacional de Aprendizaje

1

101010101010101011010101010101010110101

01010101010110101010101010101101010101

01010101101010101010101011010101010101

010110101010101010101101010101010101011

01010101010101011010101010101010110101

01010101010110101010101010101101010101

01010101101010101010101011010101010101

010110101010101010101101010101010101011

01010101010101011010101010101010110101

01010101010110101010101010101101010101

01010101101010101010101011010101010101

010110101010101010101101010101010101011

01010101010101011010101010101010110101

01010101010110101010101010101101010101

01010101101010101010101011010101010101

010110101010101010101101010101010101011

Arquitectura Lgica del Sistema

FAVA - Formacin en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje

FAVA - Formacin en Ambientes Virtuales de Aprendizaje FAVA - Formacin en Ambientes Virtuales de Aprendizaje

ARQUITECTURA LGICA DEL SISTEMA ARQUITECTURA LGICA DEL SISTEMA

SENA - Servicio Nacional de Aprendizaje SENA - Servicio Nacional de Aprendizaje

2 3

INTRODUCCIN

La arquitectura se refiere a un arte y a un estilo de construir caracterizados por ciertas particularidades. La arquitectura tradicionalmente se aplica a la construccin de edificios. En toda la historia de la humanidad las diferentes culturas han usado diferentes tcnicas, materiales y estilos en la construccin de su casa, edificios religiosos, edificios militares y edificios civiles.

En la industria del software, el trmino arquitectura se usa para describir las diferentes estructuras que forman un sistema y las relaciones entre ellas .

Como refiere Pressman (2005), En su forma ms simple, la arquitectura es la estructura u organizacin de los componentes del programa (mdulos), la manera en que stos componentes interactan y la estructura de datos que utilizan los componentes

A partir de la utilizacin del Lenguaje Unificado de Modelamiento (UML por sus siglas en Ingls) se proveern los elementos a considerar y diagramas que permitirn definir la arquitectura lgica del sistema de informacin.

ESTRUCTURA DE CONTENIDOS

Introduccin ............................................................................... 2

Mapa Conceptual ......................................................................... 4

1. Arquitectura de Software ................................................... 5

1.1. Arquitectura en capas ........................................................... 6

1.1.1. Modelo en dos capas ........................................................ 6

1.1.2. Modelo en tres capas ....................................................... 7

1.1.3. Modelo Multicapas ........................................................... 8

2. Diseo de la Arquitectura .................................................. 9

2.1. Diagrama de componentes .................................................... 10

2.1.1. Componentes ................................................................. 10

2.1.2. Interfaces ...................................................................... 12

2.1.3. Como se realiza un diagrama de componentes .................... 13

2.1.4. Subsistemas .................................................................. 16

2.2. Diagrama de paquetes ......................................................... 16

2.2.1. Elementos de un diagrama de paquetes ............................. 16

Bibliografa ................................................................................ 19

Glosario..................................................................................... 20

Control de Documentos Creative Commons y Marca Registrada ........ 21




4 5

1. ARQUITECTURA DE SOFTWARE

La arquitectura de software de un programa o de un sistema computacional, es la estructura o estructuras del sistema. Dicha estructura comprende sistemas, subsistemas, componentes e interfaces, as como las relaciones entre ellos. Debido a que la definicin de la arquitectura de un sistema se basa en modelos o abstracciones de la realidad, la arquitectura debe suprimir el detalle que no influye en la descripcin de cmo las partes usan, son usadas o se relacionan con las otras partes del sistema.

La arquitectura debe considerar tanto los requerimientos funcionales como los no funcionales: restricciones de diseo, tiempos de respuesta y disponibilidad del servicio, entre otros y debe estar preparada para recibir fcilmente requerimientos nuevos.

Dada la creciente demanda de software en todo el mundo y la dificultad para cubrir la necesidad de ingenieros preparados, la reutilizacin se ha vuelto una necesidad mayor. La arquitectura debe facilitar la identificacin temprana de oportunidades de reutilizacin y facilitar la incorporacin de partes desarrolladas y probadas con anterioridad.

La arquitectura debe considerarse la base para el mantenimiento del sistema, as mismo debe favorecer la evolucin del sistema previniendo la erosin o la descomposicin de la arquitectura debido a violacin de los principios originales y evitando caer en un caos de la arquitectura por no respetar las tendencias o rumbo establecidos para un proyecto.

En general, la arquitectura de software proporciona un marco de referencia para todo el proyecto e incorpora muchas de las decisiones ms importantes que se hacen durante el proceso de desarrollo del sistema. Podemos concluir que la arquitectura tiene cuatro funciones principales:

Constituye una base para el diseo.

Constituye la infraestructura sobre la cual se acomodan los requerimientos a travs de todo el ciclo de vida del desarrollo.

Alienta la deteccin de oportunidades de reutilizacin.

Constituye la base para el mantenimiento del sistema.

MAPA CONCEPTUAL




6 7

Aqu se organizan las funcionalidades de presentacin y procesos del negocio en una capa y la base de datos se encuentra en otra capa.

Esta estructura no facilita el mantenimiento ni la reutilizacin de componentes por lo cual no se recomienda y actualmente est en desuso.

1.1.2. Modelo en tres capas

En este modelo las tres capas se encuentran perfectamente diferenciadas, lo cual facilita su mantenimiento y reutilizacin de componentes, algunas de las caractersticas que presentan son:

Capa Presentacin:

All se encuentran la interfaz de usuario y todas aquellas utilidades relacionadas con la recepcin y presentacin de datos, tambin es la que proporciona la interfaz con la capa lgica o de negocios y por tanto enva los datos para ser procesados y posteriormente los recibe para su presentacin al usuario.

Presentacin Negocio Acceso a datos

Utilidades del Lenguaje Seguridad

Interfaz de Usuario

Web Services

Funciones de Acceso a

Datos

Utilidad de Usuario

Lgica de Procesos

WWW

BBD

1.1. ARQUITECTURA EN CAPAS

Una metodologa para particionar el sistema es usar una arquitectura de capas, donde cada capa debe cumplir con una responsabilidad claramente definida. A travs del proceso de estructuracin de metodologas de desarrollo, se han definido unas clasificaciones de acuerdo con la cantidad de capas, sin embargo es importante clarificar que todas ellas tienen tres componentes bsicos:

1.1.1. MODELO EN DOS CAPAS

Tambin se le denomina, cliente servidor, en este caso permite que usuarios finales obtengan acceso a los datos que generalmente se encuentran en otra capa. Es importante aclarar que esta separacin puede ser lgica o fsica.

Presentacin: donde se genera los procesos de entradas y salidas de datos, abarca todas las funcionalidades relacionadas con la interfaz grfica de usuario.

Lgica o procesos: provee las funcionalidades que dan respuesta a los requisitos del sistema.

Datos: funcionalidades relacionadas con el almacenamiento y manipulacin de los datos.

Manejador de base de datos DBMS

ServidorCliente




8 9

2. DISEO DE LA ARQUITECTURA

Una de las principales actividades del diseo es la particin de funcionalidad, identificada en la fase de anlisis y especificacin de requerimientos, en mdulos de software especficos. Un mdulo puede corresponder a un objeto, o un mtodo.

Especficamente, el diseo del sistema est orientado alrededor de la definicin de objetos que representan las clases que fueron identificadas durante el anlisis, dndose el mismo nfasis al diseo de los datos que a las acciones del sistema.

Los componentes de software pueden describirse en trminos de clases, paquetes, subsistemas y sus dependencias, o fsicamente en trminos de archivos ejecutables, libreras de clases y bases de datos.

En sistemas orientados a objetos la arquitectura lgica del software se modela usando diagramas de clases y diagramas de paquetes. La arquitectura fsica del software es descrita usando diagramas de componentes

Diagrama de Paquetes

Modulo de Referencia por Emergencia

Modulo de Cambio dedescripcin

Modulo de Contrareferencia

Modulo de Administracin

Modulo de Reportes

Diagrama de Paquetes

Modulo de Referencia

por Emergencia

Modulo de Cambio dedescripcin

Modulo de Contrareferencia

Modulo de Administracin

Modulo de Reportes

1.1.3. Modelo multicapas

Conservando la estructura de tres componentes principales, en este modelo se subdivide cada una de las capas, especializando los servicios que se proveen en cada una de ellas.

La cantidad de subniveles depende de la definicin de funcionalidades, pero facilita la actualizacin de las reglas de negocio, el manejo de recursos y la escalabilidad del sistema, la definicin de estas subcapas depende de las metodologas de desarrollo que se apliquen.

Capa Lgica o de Negocios:

En sta se encuentran las funcionalidades que dan respuesta a los requerimientos de la aplicacin, regidas por las pliticas del negocio, entonces son todas aquellas utilidades propias o externas que procesan los datos. Tiene interfaz con las otras capas, ya que por un lado interacta con los servicios de datos y por otro lado enva la informacin procesada para ser presentada al cliente.

Capa de Datos:

Contiene todas las funcionalidades para el acceso y manipulacin de los datos. Puede estar compuesto por el Sistema Manejador de Base de Datos o Archivos planos y las utilidades construidas para el manejo de los datos.

Presentacin

Interfaz de Usuario

Utilidad de Usuario

Serv

icio

s de

Pre

sent

aci

n

Serv

icio

s de

Con

text

o de

N

egoc

io

Negocio

Web Services

Lgica de Procesos

WWW

Serv

icio

s de

Reg

las

de N

egoc

io

Serv

icio

s de

Tra

ducc

ion

de D

atos

Serv

icio

s de

Acc

eso

a D

atos

Acceso a datos

Funciones de Acceso a

Datos

Prog

ram

aci

n de

Obj

etos

en

Base

s de

Dat

os

Serv

icio

s de

Bas

e de

Dat

os




10 11

Clases Componentes

Abstracciones LgicasT iene fragmentos fsicos

Tiene interfacesTiene operaciones y atributos

Relacin entre clase y componentes

LogicaUsuarios.dll

Componente Implementa la clase

Usuarios

Notacin

Un componente se representa con un rectngulo en el que se escribe su nombre y en l se muestran dos pequeos rectngulos al lado izquierdo.

La representacin grafica de un componente en StartUML es la siguiente.

Relacin entre los componentes:

Los componentes pueden tener relaciones de dependencia, generalizacin, asociacin (incluida agregacin) y realizacin.

Recuerde Agregacin: Un componente puede construirse a partir de otros componentes.

Logica.dll

2.1. DIAGRAMA DE COMPONENTES

Los diagramas de componentes se utilizan para describir los elementos fsicos, cdigos fuentes, las libreras, tablas, archivos y ejecutables que se van a utilizar o sern utilizados en el sistema o proyecto que se va a desarrollar junto con sus relaciones.

Los diagramas de Componentes incluyen los siguientes elementos:

2.1.1. COMPONENTES

Un componente es una parte fsica de un sistema de informacin (modulo, base de datos, programa ejecutable, etc.).

Un componente puede relacionarse, con las clases que se identificaron en la fase de anlisis (especficamente en el diagrama de clases); los componentes se pueden expresar como la materializacin de una o ms clases. Recordemos que una clase consta de atributos y mtodos, estos pueden ser implementados en los componentes.

Un componente tiene cinco estereotipos Standard:

: Componente que se puede ejecutar en un nodo.

: Representa una biblioteca de objetos esttica o dinmica.

: Representa una tabla de la base de datos.

: Representa un documento que contiene cdigo fuente o datos.

: Representa un documento.

Componentes.

Interfaces.

Relaciones de dependencia, generalizacin, asociacin y realizacin.

Paquetes o subsistemas.




12 13

2.1.3. Cmo se realiza un diagrama de componentes.

Para editar o graficar un componente y/o diagrama de componentes se utilizan herramientas CASE que soporten el modelado UML. En este material se utilizara la herramienta StarUML, una herramienta libre, sencilla de manejar y fcil de instalar, en el laboratorio correspondiente encontrar el tutorial con la informacin correspondiente a su instalacin y utilizacin.

Para construir un diagrama de componentes tenga en cuenta:

Ejemplo 1:

Descripcin del Problema:

Un sistema de facturacin para la compra y ventas de productos deportivos registra informacin referente al pedido que realiza un cliente, el contrato de venta, los datos personales de un cliente, los datos personales del distribuidor, proveedor, datos de las cuentas por cobrar. Tiene asociado el siguiente diagrama de clases.

Previamente debe tener realizado el diagrama de clases (estudiado en la fase de Anlisis); e identifique claramente: las clases que participaran en el sistema o subsistema a desarrollar y los mtodos de cada clase.

Recuerde que los mtodos en las fases de cdigo luego se convierten en mdulos con lneas de cdigo independientes.

Por ultimo los mdulos son los componentes identificados en un diagrama de componentes.

Los componentes se relacionan entre ellos por medio de las interfaces.

2.1.2. Interfaces

Los componentes implementan interfaces o acceden a los servicios proporcionados por las interfaces.

Notacin

La representacin grafica de una interfaz en StartUML es la siguiente:

Por ejemplo: Se tiene un sistema que permite el registro de los datos personales de un usuario tales como (nombre, direccin, cedula, telfono), previamente se ha definido una tabla Usuarios (almacena los usuarios del sistema, en este caso el componente identificado es de tipo y es llamado Usuarios), se defini una clase llamada RegistroDatos (en este caso el componente es de tipo , llamado Registro).

Con las interfaces podemos representar lo siguiente: El componente ejecutable genera una interfaz llamada GestindeUsuarios; el componente BuscarUsuarios utiliza la interfaz GestiondeUsuarios.

Utilidad de las interfaces

Una interfaz es utilizada por un componente para indicar:

Un componente provee una interfaz.

Un componente utiliza una interfaz.

Nombre Interfaz

Registro.exe

BuscarUsuario




14 15

Ejemplo 2:

Para las pruebas de estado ICFES que exige el Gobierno Nacional de Colombia cuenta con un sistema que permite realizar las operaciones para el ingreso de los Estudiantes a la educacin Superior o Universitaria, tales como registro de datos para poder presentar dicha prueba, consultar de la citacin y del resultado de la misma, y otras operaciones relacionadas con la intencionalidad y las caractersticas propias del examen. Estas operaciones se pueden realizar a nivel individual, como estudiante de una Institucin, o a nivel Institucional (Por Plantel), por lo cual cada uno de estos usuarios debe contar con un cdigo o documento de identificacin, y una contrasea; los usuarios individuales o particulares, el sistema les solicita un N de Documento y un PIN, a los usuarios estudiante les solicita un N de Documento y una Contrasea, y a los usuarios por institucin les solicita el cdigo del plantel y una Contrasea. Dichos datos son necesarios en todas las operaciones que se realizan en dicho sistema.

Diagrama de Clases:

Diagrama de Componentes:

Estudiante

Registro

Citacion

Cuestionario

ResultadoPrueba-Codigo -Fecha -Lugar

+AdicionarPrueba()

-Codigo -Fecha-Puntaje

+GestionarResultado()

-Fecha-Lugar-Hora

+GenerarCitacion()

-CodigoReg

-FechaReg

+GenerarRegistro()

-Codigo-Nombre-Cedula-Contrasea-Login-PIN -TipoEs

t+ObtNombre()+ObtCedula()+ObtNombre()

-Codigo -LasPreguntas+ConformarPreguntas()+GestionarCuestionario()

Preguntas

-DescripcionPreg

+GenerarPreguntas()

ConformarPreguntas

GestionarResultado

GenerarCitacion

GenerarRegistro.exe

AdicionarPrueba

GestionCuestionario

GestionResultado

GestionPrueba

Diagrama de componentes.

Teniendo el diagrama anterior, se inicia con la construccin del diagrama de componentes:

Identifique los procedimientos y/o funciones para cada clase, en el diagrama de clases de la imagen anterior las funciones se distinguen por que se encuentran ubicadas en el segundo fragmento de la clase y reciben argumentos o parmetros, por lo tanto finalizan con parntesis ().

Para la clase Cliente serian: Pedido(), ConsultaProductos(), PagoProductos().

Una vez se tienen identificados todos los mtodos de las clases se procede a realizar el diagrama de componentes:

ContratoVenta

- ContVNumContrato- ContVDetalle- ContVFecha- ContVMonto

+ ImprimirContrato()+FirmaContrato()

Pedido

- PedNum- PedFecha- PedDetalle- PedDescripcion- PedCantidad

+ RegistrarPedido()

Producto

- ProdNombre- ProdDetalle

Cliente

- CliCodigo- CliNombre- CliDireccion

- CliCedula- CliTelefono

+ Pedido()+ConsultasProducto()+PagoProductos()

Proveedor

- ProReferencia- ProNombre- ProDireccion

+ EntregarProducto()

1

11

1

1

*

*

*

*

*

*

1

1

1

RegistroStock

- RegSFecha- RegSDetalle

+ Busqueda()+ActualizacionRegistro() Registra

Entrega

Registra

RealizaRealiza

Provee

Distribuidor

- DisCodigo- DisNombre- DisDireccion- DisTelefono

+ EntregaPedido()+Cobro Factura()+CobroDeudaPendiente()

Distribuidor

- CuentPCDetalle- CuentPCFecha- CuentPCMonto

+ BuscarCuenta()+ Actualizar()

Registro.exe

BuscarUsuario

ImprimirContrato

ElaborarContrato

PagarProductos

BuscarCuenta

RejistrarPedido

BuscarUnidadesStock

ColorDeudaPendiente

GestionUsuariosGestionPedido




16 17

Notacin

Un paquete se representa con un icono con forma de carpeta y con el nombre colocado dentro del icono.

Dependencia

Ejemplo 1:

Nombre

Paquete Negocio

+ Ejemplar+ Prstamo+ Ttulo+ Informacin del prestatario+ Ttulo del libro+ Reserva+ Titulo de la revista

Paquete de Utilidad

+ Objeto ID

Paquete de BD

+ Persistencia# Eliminacin

Paquete G UI

+ Ventana de Prstamos+ Ventana de Devoluciones+ Ventana de Reservas+ Ventana de Mantenimiento

2.1.4. Subsistemas

Permiten dividir en sistemas ms pequeos el sistema actual, un subsistema puede contener componentes y a la vez subsistemas.

Se debe tener en cuenta que la relacin entre paquetes y clases en el nivel lgico es el que existe entre subsistemas y componentes en el nivel fsico.

2.2. Diagramas de paquetes

Los diagramas de paquetes se utilizan para organizar el sistema en subsistemas, agrupando elementos del anlisis, diseo o construccin y detallando las relaciones de dependencia entre ellos.

Es decir, se hace necesario organizar el sistema en bloques menores para comprender fcilmente el sistema por completo. Aplicando la frase divide y vencers.

2.2.1. Elementos de un diagrama de paquetes

Paquetes

Un paquete permite agrupar varios elementos, bien sea casos de uso, clases o componentes. Los paquetes pueden contener otros paquetes por dentro, lo que se llama paquetes anidados, donde el paquete hijo contendr nuevos elementos tales como los nombrados anteriormente.

Relaciones de dependencia:

Los paquetes se relacionan entre ellos y pueden la relacin se llama de dependencia, la cual significa que un elemento de un paquete requiere de otro que pertenece a un paquete distinto. Es importante resaltar que las dependencias no son transitivas.

Las dependencias se representan con una flecha discontinua con inicio en el paquete que depende del otro.




18 19

BILBIOGRAFIA

Pressman, Roger (2005). Ingeniera de Software Un enfoque prctico. McGraw Hill. 6 edicin.

Rodrguez Dez, Gustavo. Arquitectura de Capas. Material del Curso Metodologas de Diseo de Sistemas 2. ITESM Campus Monterrey, 2006

Booch, Rumbaugh y Jacobson (2006): El Lenguaje Unificado de Modelado. 2 edicin.

Rumbaugh, Jacobson y Booch (2007): El Lenguaje Unificado de Modelado. Manual de Referencia. 2 edicin.

Sugerencias y consejos

Los paquetes slo existen para ayudar a organizar los elementos del modelo. Si se tienen abstracciones que se manifiestan como objetos no se deben utilizar paquetes.

Un paquete bien estructurado:

Es cohesivo

Est poco acoplado: exporta slo aquellos elementos que otros paquetes necesitan ver realmente.

No est profundamente anidado

Posee un conjunto equilibrado de elementos; no deben ser demasiado grandes en relacin con otros




20 21

Control de documentoConstruccin Objeto de Aprendizaje

Arquitectura Lgica del SistemaDesarrollador de contenido Experto temtico

Leydy carolina Muoz

Asesor pedaggico Rafael Neftal Lizcano Reyes Claudia Milena Hernndez

Produccin Multimedia Jose Luis Virviescas Pulido Victor Hugo Tabares Carreo

Programadores Daniel Eduardo Martnez Daz Grateful Dead Montao Sierra

Lder expertos temticos Ana Yaqueline Chavarro Parra

Lder lnea de produccin Santiago Lozada Garcs

GLOSARIO

Diagrama de componentes: Describen los elementos fsicos, cdigos fuentes, las libreras, tablas, archivos y ejecutables que se van a utilizar para modelar un sistema de informacin.

Componente: Parte fsica de un sistema de informacin (modulo, base de datos, programa ejecutable).

Subsistemas: Dividir en sistemas ms pequeos el sistema actual.

Paquetes: Permite agrupar varios elementos, bien sea casos de uso, clases o componentes.

Diagrama de paquetes: Se utilizan para organizar el sistema en subsistemas, agrupando elementos del anlisis, diseo o construccin y detallando las relaciones de dependencia entre ellos.

Diagrama de despliegue: Modelan el hardware y/o conexiones fsicas entre los componentes hardware y software que se utilizara en la implementacin final del sistema y la relacin entre sus componentes, describen la configuracin del sistema para su ejecucin en un ambiente del mundo real.

Nodo: Objetos fsicos que existen en tiempo de ejecucin, y que representan algn tipo de recurso computacional (capacidad de memoria y procesamiento).

diseño dmuy bueno

Documents

Transcript of diseño dmuy bueno