3.1 ARQUITECTURA DE CLASES
El diseño arquitectónico es el proceso a través del
cual se identifican los subsistemas que componen un sistema de información, así
como los mecanismos de control y comunicación usados por los mismos el
resultado de este proceso es una descripción de la arquitectura del software.
Etapa
temprana en el proceso de desarrollo de un sistema de información es el enlace
entre la especificación del sistema y el desarrollo del mismo Implica
identificar los principales componentes del sistema y su mecanismo de
comunicación.
Ventajas
Ø Reutilización a gran escala
Ø Análisis del sistema (requerimientos no funcionales)
Ø Se expresa como un diagrama de bloques presentando una visión general del sistema.
Ø En caso de que sea necesario, se puede aumentar el detalle de algún subsistema importante.
Ø Existe algún ejemplo de
arquitectura genérica que pueda aplicarse?
Ø Como se distribuirá el sistema?Ø Algún estilo de arquitectura es aplicable?
Ø Como se descompondrá el sistema en módulos?
Ø Como se controlaran y comunicaran esos módulos?
El modelo
arquitectónico de un sistema puede basarse en un estilo o modelo genérico de
arquitectura conocer estos modelos de antemano puede facilitar la tarea de
definir la arquitectura de un sistema en los grandes sistemas, son
heterogéneos, no siguiendo un claro estilo arquitectónico único.
Modelos
arquitectónicos
Ø Usados para documentar la arquitectura de un sistema
Ø Modelos estáticos estructurales
Ø Modelos dinámicos de procesos
Ø Modelos de interfaces
Ø Modelos de datos
Ø Modelos de deployment
INCO -Facultad de Ingeniería –
Montevideo, Uruguay 11
Ø Servidores y servicios compartidos
Ø Maquina abstracta o basado en capas
Repositorio común
Los subsistemas deben intercambiar datos
Ø Los datos se almacenan en un repositorio o base de datos central, y los subsistema acceden a estos
Ø Los subsistemas mantienen los datos internamente, intercambiándolos explícitamente según sea necesario para grandes volúmenes de datos, la primera opción es la recomendada.
3.2
IDENTIFICACIÓN DE CLASES SEGÚN ESTEREOTIPOS
Para llevar
a cabo la transición del modelo de requisitos al modelo de análisis se deben
identificar los objetos necesarios para implementar todos los casos de uso. La
arquitectura de objetos debe considerar los tres tipos de estereotipos de
objetos. Para ello se deben identificar primero las clases borde, las
clases entidad y finalmente las de Control.
Para llevar
a cabo la transición del modelo de requisitos al modelo de análisis se deben
identificar los objetos necesarios para implementar todos los casos de uso. La
arquitectura de objetos debe considerar los tres tipos de estereotipos de
objetos. Para ello se deben identificar primero las clases borde, las
clases entidad y finalmente las de Control.
Los cambios a la funcionalidad son más difíciles
de administrar, ya que ésta puede abarcar todos los tipos de objetos.
Bordes
Toda la funcionalidad especificada en las
descripciones de los casos de uso que depende directamente de los aspectos
externos del sistema, se ubica en los objetos borde, pues a través de ellos se
comunican los actores con el sistema. La tarea de una clase borde es traducir
los eventos generados por un actor en eventos comprendidos por el sistema, y
traducir los eventos del sistema en una presentación comprensible para el
actor.
Las clases borde en otras palabras, describen la
comunicación bidireccional entre el sistema y los actores.
Las clases borde son bastante fáciles de
identificar, donde se cuenta con al menos tres estrategias:
1. Se pueden identificar con base a los actores.
2. Se pueden identificar con base en las
descripciones de las interfaces del sistema que acompañan al modelo de
requisitos.
3. Se pueden identificar con base en las
descripciones de los casos de uso y extraer la funcionalidad específica a los
objetos bordes.
Entidad
Se utilizan objetos entidad para modelar la
información que el sistema debe manejar a corto y largo plazo. La información a
corto plazo existe durante la ejecución de un caso de uso, mientras que la
información a largo plazo trasciende los caso de uso, por lo que es necesario
guardarla en alguna base de datos o archivos.
Durante la identificación de objeto entidad, se
encontrara que objetos que objetos similares aparecen en varios casos de uso.
Ofrecer
Servicios: Este caso de uso administra las opciones de servicio y no requiere de
ninguna clase entidad.
Registrar
Usuario: Este caso de uso requiere guardar información exclusivamente acerca
del usuario, lo que se hace en la clase entidad Registro-Usuario.
Registrar
Tarjeta: Este caso de uso requiere guardar información exclusivamente acerca de
la tarjeta del usuario lo que hace en la clase entidad RegistroTarjeta.
Consultar
Información: Este casi de uso requiere de toda la información relacionada con
consultas. Se puede tomar las clases del dominio del problema y quitar aquellas
relacionadas con registros y reservaciones.
Hacer
reservación: Este caso de uso requiere de la información relacionada con
reservaciones. Se pueden tomar las clases del dominio del problema y quitar
aquellas relacionadas con registros.
Pagar
Reservación: Este caso de uso requiere de la información relacionada con
reservaciones. Dado que es una extensión al caso de uso Hacer Reservación, no
es necesario volver a repetir todas las clases entidad, sino más bien
especificar cualquier clase adicional.
Control
En la mayoría de los casos de uso, existe un
comportamiento que no se puede asignar de forma natural a ninguno de los otros
dos tipos de objetos ya vistos. Una posibilidad es repartir el comportamiento
entre los dos tipos de objetos, pero la solución no es buena si se considera el
aspecto de extensibilidad.
Un cambio en el comportamiento podría afectar
varios objetos, dificultando su modificación. Para evitar estos problemas, tal
comportamiento se asigna a objetos control.
Es difícil lograr un buen balance en la
distribución del comportamiento del caso de uso entre los objetos entidad,
borde y control. Los objetos de control normalmente proveen a administración de
los demás tipos de objetos.
3.3 CLASES
Clase de Interfaz
Las clases de interfaz se
utilizan para modelar la interacción entre el sistema y los actores entre el
sistema y los actores. Las clases de interfaz modelan las partes del sistema de
dependen de sus actores, lo cual implica que se clasifican y reúnen los
requisitos en los límites del sistema. Las clases de interfaz representan a
menudo abstracciones de ventanas formularios, paneles interfaces de
comunicaciones.
Clases de Entidad
Las
clases de entidad modelan información y el comportamiento asociado de algún
fenómeno o concepto, como persona o un objeto. También reflejan la información
de un modo que beneficia a los desarrolladores al diseñar e implementar el
sistema, incluyendo su soporte de persistencia, suelen mostrar una estructura
de datos lógicos y contribuyen a comprender de que información depende el
sistema.
Clase de Gestor
Las
clases de control representan coordinación, secuencia transacciones y control
de otros objetos y se usan con frecuencia para encapsular el control de un caso
de uso en concreto.
Los
aspectos dinámicos del sistema se modelan con clases de control, debido a que
ellas manejan y coordinan las acciones y los flujos de control principales, y
delegan trabajo a otros objetos.
3.4 DIAGRAMAS DE
SECUENCIAS
Diagrama de secuencia muestra a secuencia
cronológica de mensajes entre objetos durante un escenario concreto.Cada objeto
viene dado por una barra ver C cal.
El tiempo transcurre de arriba abajo.Cuando existe
demora entre el envío y la atención se puede indicar usando una línea oblicua.
Utilidad del Diagrama de Secuencia:
Ø Para la documentación de un Caso
de Uso:En términos próximos al usuario y sin detallar la sincronización
existente.
Ø Para la representación precisa de
las interacciones entre objetos.
Gráficamente también se puede indicar cuándo el
mensaje es para crear el objeto (va dirigido al rectángulo del objeto o
etiquetado con new) o para
destruirlo (va dirigido a la línea del objeto pero el final de la flecha es una
cruz).
Diagrama de secuencia
Ø Normalmente no es necesario
indicar el retorno del control en mensajes síncronos.
Ø En el caso asíncrono el retorno,
si existe, se debe representar.
Tipos de control
Ø Un control centralizado Cene una forma como esta:
Un control descentralizado Cene una forma como
esta:
3.5. DICCIONARIO
DE CLASES SEGUN MODULOS
Módulos
Interface-Usuario
• Interface-Usuario – Clase Borde. Toda la
interacción con el usuario se hace por medio de la borde de usuario.
Principal
• Pantalla-Principal - Clase Borde. Pantalla
principal (P-1).
• Manejador-Principal - Clase Control. El
manejador principal es el encargado de desplegar la pantalla principal de
interacción con el usuario, y luego delegar las diferentes funciones a los
manejadores especializados apropiados.
Usuario
• Pantalla-Crear-Reg-Usuario - Clase Borde.
Pantalla de solicitud de registro de usuario (P-3).
• Pantalla-Obtener-Reg-Usuario - Clase
Borde. Pantalla de devolución con información de registro de usuario (P-4).
• Registro-Usuario - Clase Entidad. Para
poder utilizar el sistema de reservaciones, el usuario debe estar registrado
con el sistema. El registro contiene información acerca del usuario que incluye
nombre, dirección, colonia, ciudad, país, código postal, teléfono de casa,
teléfono de oficina, fax, email, login y password.
• Manejador-Registro-Usuario - Clase
Control. El manejador de registro de usuario se encarga de todo lo relacionado
con registro del usuario para poder utilizar el sistema.
Tarjeta
• Pantalla-Crear-Reg-Tarjeta-
Clase Borde. Pantalla de solicitud de registro de tarjeta (P-5).
• Pantalla-Obtener-Reg-Tarjeta – Clase Borde
. Pantalla de devolución con información deregistro de tarjeta (P-6).
3.6 HERRAMIENTAS CASE PARA EL ANÁLISIS.
Componentes De Una Herramienta Case
Una herramienta case podemos
decir que se compone de:
• Un
diccionario donde se almacenan los elementos creados por la herramienta, cuya
gestión se realiza mediante el apoyo de un sistema de Gestión de base de datos
(SGBD).
• El
meta modelo, que constituye el marco para la definición de técnicas y
metodologías soportadas por la herramienta. No siempre es visible.
• La
carga o descarga de datos, permiten cargar el repertorio de la herramienta CASE
con datos provenientes de otros sistemas, o generan a partir de la propia
herramienta esquemas de base de datos, programas, pueden alimentar otros
sistemas. Este elemento proporciona un medio de comunicación con otras
herramientas.
• Una
comprobación de errores que permiten llevar a cabo un análisis de la exactitud,
integridad y consistencia de los esquemas generados por la herramienta.
• Una
interfaz de usuario, que constará de editores de texto y herramientas de diseño
gráfico que permitan la utilización de un sistema de ventanas, iconos y menús,
con la ayuda del ratón, definir los diagramas, matrices.
Estructura General De Un Herramienta Case
La estructura CASE se basa en lo
siguiente
• Un
CASE de alto nivel es la herramienta que automatiza o apoya las fases
superiores del ciclo de vida del desarrollo de sistemas como la planificación
de sistemas, el análisis de sistemas y el diseño de sistemas.
• Un
CASE de bajo nivel es la herramienta que automatiza o apoya las fases
inferiores del ciclo de vida como el diseño detallado de sistemas, la
implantación de sistemas y el soporte de sistemas.
• Un
CASE cruzado de ciclo de vida se aplica a las herramientas que apoyan
actividades a lo largo de todo el ciclo de vida, se incluyen actividades como
la gestión de proyectos y la estimación.
Estado Actual
En las últimas décadas se ha
trabajado en el desarrollo de sistemas para encontrar técnicas para incrementar
la productividad y calidad en el proceso de elaboración del software, hoy la
herramienta CASE (ComputerAided Software Engineering) a remplazado el papel y
lápiz por el ordenador para la transformación del desarrollo de software en un
proceso automatizado.
La tecnología CASE supone la
automatización del desarrollo de software para elevar la productividad y la
calidad en el desarrollo de sistemas análogas a lo que suponen las técnicas
CAD/CAM en este enfoque permite mejorar la calidad del software.
• La
mejora y la estandarización de la documentación.
• Aumentar
la portabilidad de las aplicaciones.
• Facilitar
la reutilización de componentes de software
• Permitir
un desarrollo y un refinamiento de las aplicaciones, mediante la utilización de
controles gráficos.
Clasificación De Las Herramientas Case
Las herramientas no tienen una
única clasificación y es difícil determinarle en una clase y pueden ser
clasificadas de acuerdo a
- Las plataformas que soportan.
- Las fases del ciclo de vida del
desarrollo de sistemas que cubren.
- La arquitectura de aplicaciones
que producen.
- Su funcionalidad.
CASE es una combinación de
herramientas software y de metodologías de desarrollo:
La herramienta permite
automatizar el proceso de desarrollo del software
La metodología define los
procesos automatizados
La primera clasificación del
CASE:
TOOLKIT: Es la
colección de herramientas que permiten automatizar un conjunto de tareas de las
fases del ciclo de vida del sistema informático, planificación estratégica,
Análisis, Diseño y Generación de programas.
WORKBENCH: Son
conjuntos de herramientas que dan soporte a la automatización del proceso de
desarrollo del sistema informático. Permiten cubrir el ciclo de vida completo.
El producto final aportado es un sistema en código ejecutable y su
documentación.
La segunda clasificación es
teniendo en cuenta el ciclo de vida que automatizan:
UPPER CASE:
Requerimientos de Desarrollo Funcional de Planes Corporativos.
MIDDLE CASE:
Análisis y Diseño.
LOWER CASE:
Generación de código, e implantación.
Características Deseables De Una Case
La herramienta CASE
cliente/servidor tiene modelo de datos, generación de código de ciclo de vida. Las
principalesherrameintas son Knowledge Ware’s Application Development Workbench,
TI’s, Information Engineering Facility (IEF), y Andersen consulting’s
Foundation for Cooperative Processing.
Deberes de la herramienta CASE
La herramienta debe proporcionar
facilidades de construcción para separar la aplicación entre el cliente,
servidor y entre servidores.
La herramienta debe crear códigos
para Windows, OS/2 Macintosh, Unix y plataformas de servidores conocidas,
desplegar la versión correcta del código en la maquina apropiada.
La herramienta debe reconocer las
versiones de códigos que se ejecuta en los clientes y servidores y que sean
consistentes.
La herramienta debe ser capaz de
controlar gran numero de tipos de objetos incluyendo, texto, gráficos, mapas de
bits. Debe mantener versiones de objetos con niveles arbitrarios de
granularidad.
La herramienta debe compilar
automáticamente código 4GL en el servidor.
La herramienta debe adaptarse a
los administradores de recursos que existen en servidores de red su interacción
con los administradores deberá ser negociable a tiempo de ejecución.
La
herramienta trabajar con software intermedia debe adaptar sus comunicaciones
cliente/servidor al software intermedio la herramienta debe ajustarse basándose
si se esta moviendo en una LAN o WAN.
Ø [UML 2.0] Unified Modeling
Language: Superstructure v 2.0 (ago2005)
http://www.omg.org/cgi-bin/doc?formal/05-07-04
Ø G. Booch, J. Rumbaugh, I.
Jacobson, El Lenguaje Unificado de
Modelado(UML
2.0) 2ª
Edición. Addison Wesley, 2006
.
No hay comentarios:
Publicar un comentario