I. 1 Introducción



Descargar 0,73 Mb.
Página8/9
Fecha de conversión12.01.2017
Tamaño0,73 Mb.
1   2   3   4   5   6   7   8   9

III.2.2.2 Nodos y componentes 
En muchos aspectos los nodos y los componentes tienen características parecidas. Vamos a ver con más detalle cuales son los parecidos y las diferencias entre los componentes y los nodos. 

PARECIDOS


Ambos tienen nombre
Pueden participar en relaciones de dependencia, generalización y asociación.
Ambos pueden anidarse
Ambos pueden tener instancias
Ambos pueden participar en interacciones 

DIFERENCIAS 


Los Nodos Los Componentes
Son los elementos donde se ejecutan los componentes. Son los elementos que participan en la ejecución de un sistema.
Representan el despliegue físico de los componentes. Representan el empaquetamiento físico de los elementos lógicos.
La relación entre un nodo y los componentes que despliega se pueden representar mediante una relación de dependencia como se indica en la Figura 32.
Los nodos se pueden agrupar en paquetes igual que los las clases y los componentes. 
Los tipos de relación más común entre nodos es la asociación. Una asociación entre nodos viene a representar una conexión física entre nodos como se puede ver en la Figura 33.

 
Figura 32 Relación entre nodos y componentes 
 
Figura 33 Conexiones entre nodos 
Existen dos tipos de diagramas que sirven para modelar los aspectos físicos de un sistema orientado a objetos:
• Diagramas de Componentes
• Diagramas de Despliegue
Seguidamente veremos para qué sirve cada uno de ellos y cual es su representación gráfica. 

III.2.3 Diagramas de Componentes 
Un diagrama de componentes muestra la organización y las dependencias entre un conjunto de componentes. Para todo sistema OO se han de construir una serie de diagramas que modelan tanto la parte estática (diagrama de clases), como dinámica (diagramas de secuencia, colaboración, estados y de actividades), pero llegado el momento todo esto se debe materializar en un sistema implementado que utilizará partes ya implementadas de otros sistemas, todo esto es lo que pretendemos modelar con los diagramas de componentes. 

III.2.3.1 Algunos conceptos 
Un diagrama de componentes muestra un conjunto de componentes y sus relaciones de manera gráfica a través del uso de nodos y arcos entre estos. 
Normalmente los diagramas de componentes contienen:
• Componentes
Interfaces
• Relaciones de dependencia, generalización, asociaciones y realización.
• Paquetes o subsistemas
• Instancias de algunas clases 
Visto de otro modo un diagrama de componentes puede ser un tipo especial de diagrama de clases que se centra en los componentes físicos del sistema. 

III.2.3.2 Usos más comunes 
a) Modelado de Código Fuente 
Los diagramas de componentes se pueden utilizar para modelar la gestión de la configuración de los archivos de código fuente, tomando como productos de trabajo precisamente estos ficheros. Esto resulta bastante útil por ejemplo cuando se han implementado unas partes con Java otras con C, etc. El resultado de esta implementación pueden ser multitud de ficheros ejecutables con características particulares, de manera que la mejor forma de controlarlos es estableciendo gestión de configuración. 
Para poder llevar a cabo esta gestión con éxito será necesario definir los estereotipos de ficheros que se quieren tener bajo control así como las relaciones entre dichos tipos de ficheros. 
Para modelar el código fuente de un sistema:
• Hay que identificar el conjunto de archivos de código fuente de interés y modelarlos como componentes estereotipados como archivos.
• Si el sistema es muy grande es necesario utilizar los paquetes para agrupar los archivos de código fuente.
• Es necesario identificar la versión del componente.
b) Modelado de una versión ejecutable y bibliotecas.
La utilización de los componentes para modelar versiones ejecutables se centra en la definición de todos los elementos que componen lo que se conoce como versión ejecutable, es decir la documentación, los ficheros que se entregan etc.
Para modelar una versión ejecutable es preciso:
• Identificar el conjunto de componentes que se pretende modelar.
• Identificar el estereotipo de cada componente del conjunto seleccionado.
• Para cada componente de este conjunto hay que considerar las relaciones con los vecinos. Esto implica definir las interfaces importadas por ciertos componentes y las exportadas por otros.
c) Modelado de una base de datos física
Para modelar una base de datos física es necesario:
• Identificar las clases del modelo que representan el esquema lógico de la base de datos.
• Seleccionar una estrategia para hacer corresponder las clases con tablas. Así como la distribución física de la/s base/s de datos.
Para poder visualizar, especificar, construir y documentar dicha correspondencia es necesario crear un diagrama de componentes que tenga componentes estereotipados como tablas.
• Donde sea posible es aconsejable utilizar herramientas que ayuden a transformar diseño lógico en físico. 

III.2.4 Diagramas de Despliegue 
III.2.4.1 Técnicas más comunes de modelado 
a) Modelado de un sistema empotrado
El desarrollo de un sistema empotrado es más que el desarrollo de un sistema software. Hay que manejar el mundo físico. Los diagramas de despliegue son útiles para facilitar la comunicación entre los ingenieros de hardware y los de software.
Para modelar un sistema empotrado es necesario:
• Identificar los dispositivos y nodos propios del sistema.
• Proporcionar señales visuales, sobre todo para los dispositivos poco usuales.
• Modelar las relaciones entre esos procesadores y dispositivos en un diagrama de despliegue.
• Si es necesario hay que detallar cualquier dispositivo inteligente, modelando su estructura en un diagrama de despliegue más pormenorizado.
b) Modelado de un sistema cliente servidor
La división entre cliente y servidor en un sistema es complicada ya que implica tomar algunas decisiones sobre dónde colocar físicamente sus componentes software, qué cantidad de software debe residir en el cliente, etc.
Para modelar un sistema cliente/servidor hay que hace lo siguiente:
• Identificar los nodos que representan los procesadores cliente y servidor del sistema.
• Destacar los dispositivos relacionados con el comportamiento del sistema.
• Proporcionar señales visuales para esos procesadores y dispositivos a través de estereotipos.
• Modelar la tipología de esos nodos mediante un diagrama de despliegue. 

III.2.5 Arquitectura del Sistema 
III.2.5.1 Arquitectura de tres niveles 
La llamada “Arquitectura en Tres Niveles”, es la más común en sistemas de información que además de tener una interfaz de usuario contemplan la persistencia de los datos. 
Una descripción de los tres niveles sería la siguiente:
Nivel 1: Presentación – ventanas, informes, etc.
Nivel 2: Lógica de la Aplicación – tareas y reglas que gobiernan el proceso.
Nivel 3: Almacenamiento – mecanismo de almacenamiento. 

III.2.5.2 Arquitectura de tres niveles orientadas a objetos 
a) Descomposición del nivel de lógica de la aplicación
En el diseño orientado a objetos, el nivel de lógica de la aplicación se descompone en sub-niveles que son los siguientes: 
Objetos del Dominio: son clases que representan objetos del dominio. Por ejemplo en un problema de ventas, una “Venta” sería un objeto del dominio.
Servicios: se hace referencia a funciones de interacción con la base de datos, informes, comunicaciones, seguridad, etc. 

III.2.5.3 Arquitectura MULTI-nivel 
La arquitectura de tres niveles puede pasar a llamarse de Múltiples Niveles si tenemos en cuenta el hecho de que todos los niveles de la arquitectura de tres niveles se pueden descomponer cada uno de ellos cada vez más. 
Por ejemplo el nivel de Servicios, se puede descomponer en servicios de alto y de bajo nivel, identificando como de alto nivel los servicios de generación de informes y como de bajo nivel los de manejo de ficheros de entrada y salida. 
El motivo que lleva a descomponer la arquitectura del sistema en diferentes niveles es múltiple: 
• Separación de la lógica de la aplicación en componentes separados que sean más fácilmente reutilizables.
• Distribución de niveles en diferentes nodos físicos de computación.
• Reparto de recursos humanos en diferentes niveles de la arquitectura. 

III.2.5.4 Paquetes 
La forma que tiene UML de agrupar elementos en subsistemas es a través del uso de Paquetes, pudiéndose anidar los paquetes formando jerarquías de paquetes. De hecho un sistema que no tenga necesidad de ser descompuesto en subsistemas se puede considerar como con un único paquete que lo abarca todo. 
Gráficamente un paquete viene representado como se indica en la Figura 34. 
 
Figura 34 Representación de un paquete en UML 
En la Figura 35, vemos cómo se representa la arquitectura del sistema con la notación de paquetes. 
 
Figura 35 Arquitectura de un sistema utilizando paquetes 

III.2.5.5 Identificación de Paquetes 
Vamos a definir una serie de reglas que nos pueden ser de utilidad a la hora de agrupar los diferentes elementos en paquetes.
• Conviene agrupar elementos que proporcionen un mismo servicio.
• Los elementos que se agrupen en un mismo paquete han de presentar un alto grado de cohesión, es decir deben estar muy relacionados.
• Los elementos que estén en diferentes paquetes deben tener poca relación, es decir deben colaborar lo menos posible. 

IV.1 Proceso de Desarrollo

Cuando se va a construir un sistema software es necesario conocer un lenguaje de programación, pero con eso no basta. Si se quiere que el sistema sea robusto y mantenible es necesario que el problema sea analizado y la solución sea cuidadosamente diseñada. Se debe seguir un proceso robusto, que incluya las actividades principales. Si se sigue un proceso de desarrollo que se ocupa de plantear cómo se realiza el análisis y el diseño, y cómo se relacionan los productos de ambos, entonces la construcción de sistemas software va a poder ser planificable y repetible, y la probabilidad de obtener un sistema de mejor calidad al final del proceso aumenta considerablemente, especialmente cuando se trata de un equipo de desarrollo formado por varias personas. 


Para este curso se va a seguir el método de desarrollo orientado a objetos que propone Craig Larman [Larman99]. Este proceso no fija una metodología estricta, sino que define una serie de actividades que pueden realizarse en cada fase, las cuales deben adaptarse según las condiciones del proyecto que se esté llevando a cabo. Se ha escogido seguir este proceso debido a que aplica los últimos avances en Ingeniería del Software, y a que adopta un enfoque eminentemente práctico, aportando soluciones a las principales dudas y/o problemas con los que se enfrenta el desarrollador. Su mayor aportación consiste en atar los cabos sueltos que anteriores métodos dejan. 
La notación que se usa para los distintos modelos, tal y como se ha dicho anteriormente, es la proporcionada por UML, que se ha convertido en el estándar de facto en cuanto a notación orientada a objetos. El uso de UML permite integrar con mayor facilidad en el equipo de desarrollo a nuevos miembros y compartir con otros equipos la documentación, pues es de esperar que cualquier desarrollador versado en orientación a objetos conozca y use UML (o se esté planteando su uso). 
Se va a abarcar todo el ciclo de vida, empezando por los requisitos y acabando en el sistema funcionando, proporcionando así una visión completa y coherente de la producción de sistemas software. El enfoque que toma es el de un ciclo de vida iterativo incremental, el cual permite una gran flexibilidad a la hora de adaptarlo a un proyecto y a un equipo de desarrollo específicos. El ciclo de vida está dirigido por casos de uso, es decir, por la funcionalidad que ofrece el sistema a los futuros usuarios del mismo. Así no se pierde de vista la motivación principal que debería estar en cualquier proceso de construcción de software: el resolver una necesidad del usuario/cliente. 

IV.1.1 Visión General 
El proceso a seguir para realizar desarrollo orientado a objetos es complejo, debido a la complejidad que nos vamos a encontrar al intentar desarrollar cualquier sistema software de tamaño medio-alto. El proceso está formado por una serie de actividades y subactividades, cuya realización se va repitiendo en el tiempo aplicadas a distintos elementos. 
En este apartado se va a presentar una visión general para poder tener una idea del proceso a alto nivel, y más adelante se verán los pasos que componen cada fase. 
Las tres fases al nivel más alto son las siguientes: 
• Planificación y Especificación de Requisitos: Planificación, definición de requisitos, construcción de prototipos, etc. 
• Construcción: La construcción del sistema. Las fases dentro de esta etapa son las siguientes: 
     - Diseño de Alto Nivel: Se analiza el problema a resolver desde la perspectiva de los usuarios y de las entidades externas que van a solicitar servicios al sistema. 
     - Diseño de Bajo Nivel: El sistema se especifica en detalle, describiendo cómo va a funcionar internamente para satisfacer lo especificado en el Diseño de Alto Nivel. 
     - Implementación: Se lleva lo especificado en el Diseño de Bajo Nivel a un lenguaje de programación. 
     - Pruebas: Se llevan a cabo una serie de pruebas para corroborar que el software funciona correctamente y que satisface lo especificado en la etapa de Planificación y Especificación de Requisitos. 
• Instalación: La puesta en marcha del sistema en el entorno previsto de uso. 
De ellas, la fase de Construir es la que va a consumir la mayor parte del esfuerzo y del tiempo en un proyecto de desarrollo. Para llevarla a cabo se va adoptar un enfoque iterativo, tomando en cada iteración un subconjunto de los requisitos (agrupados según casos de uso) y llevándolo a través del diseño de alto y bajo nivel hasta la implementación y pruebas, tal y como se muestra en la Figura 36. El sistema va creciendo incrementalmente en cada ciclo. Con esta aproximación se consigue disminuir el grado de complejidad que se trata en cada ciclo, y se tiene pronto en el proceso una parte del sistema funcionando que se puede contrastar con el usuario/cliente. 
 
Figura 36 Desarrollo Iterativo en la Construcción 
1   2   3   4   5   6   7   8   9


La base de datos está protegida por derechos de autor ©absta.info 2016
enviar mensaje

    Página principal