Modulos de vista

22
Módulos de vista Gestión de Proyectos de Software Ortega Vásquez Edith Salinas Zavaleta Eleazar Sarmiento Ruiz Adolfo

Transcript of Modulos de vista

Módulos de vistaGestión de Proyectos de Software

Ortega Vásquez Edith

Salinas Zavaleta Eleazar

Sarmiento Ruiz Adolfo

Elementos Relaciones Propiedades

Propósito NotaciónRelación con otras

vistas

Contenido

Veremos la manera de documentar las estructuras de módulos de software de

un sistema. Dicha documentación enumera las principales unidades de

ejecución, o módulos, de un sistema, junto con las relaciones entre estas

unidades.

Nos referimos a estas descripciones como módulo vistas.

1.1 Información general

Elementos: Módulos, que son las unidades de ejecución de software que

proporcionan un marco coherente conjunto de responsabilidades.

Relaciones:

• Es parte de, lo que define una parte de toda relación entre el submódulo y la

parte del modulo agregado – el todo el sistema.

• Depende, que define una relación de dependencia entre dos módulos.

• Es una, que define una relación de generalización / especialización entre un

módulo.

Resumen del modulo de vista

Los diseñadores utilizan el término modulo para referirse a una amplia

variedad

de estructuras de software, incluyendo lenguajes de programación, tales como

programas en C, Java o C#, Delphi,SQL procedimientos almacenados o

simplemente agrupaciones generales de Unidades de código fuente como los

paquetes de Java o espacios de nombres de C#.

Un módulo se caracteriza por enumerar sus actividades, además de que

pueden ser agregados o descompuestos.

1.2.1 Elementos

Los módulos de vista tienen las siguientes tipos de relaciones

Es parte de. La parte de la relación define una parte/todo- Entre el

submódulo y la agrega al sistema en su totalidad.

Depende de. A depende de B en una relación, hay diferentes formas

específicas de un conjunto de dependencias que se pueden utilizar en el

módulo de vista .

Es un . En esta relación entra con más detalle en la generalización

1.2.2 Las Relaciones

Las propiedades de los módulos que ayudan a orientar la aplicación o de

entrada a análisis se deberán registrar como parte de la documentación de

apoyo para el módulo. La lista de propiedades pueden variar, pero es

probable que incluyen las siguientes:

• Nombre. El nombre del módulo es, por supuesto, el principal medio de

referencia al mismo. El nombre del módulo a menudo sugiere algo sobre Su

función en el sistema.

• Responsabilidad. La responsabilidad de un módulo es una forma de

determinar su papel en el sistema global y establece una identidad para

que fuera más allá del nombre. Las responsabilidades deben ser descritos

con suficiente detalle para dejar claro al lector qué hace cada módulo

1.2.3 Propiedades

Visibilidad de interface(s). Cuando un módulo tiene submódulos, algunas

interfaces de los submodulos internas puede tener uso; es decir las interfaces

solo son utilizados por el submodulo.

El Módulo C proporciona su

interfaz propia, ocultando la

las interfaces de los módulos A

y B. (b) Módulo C

expone un subconjunto de la

las interfaces de los módulos A

y B ya que su interfaz

1.2.3 Propiedades

Implementación de la información. Gracias a que los módulos son

unidades de Aplicación, es útil registrar la información relacionada con su

aplicación desde el punto de vista de la gestión, su desarrollo y creación del

sistema que contiene.

Esa información puede ser útil para guardarla en la documentación de la

arquitectura donde se define el módulo.

1.2.3 Propiedades

Asignación de unidades de código fuente. Esto identifica los archivos que Constituyen la

aplicación de un módulo. Por ejemplo, Un módulo denominado cuenta, si implementado en

Java, tal vez Tienen varios archivos que constituyen su aplicación:

IAccount.java (una interfaz), AccountImpl.java (una apli-Funcionalidad de

cuenta), AccountBean.java (Una clase para mantener el estado de una cuenta en la memoria.)

Información de la prueba. El módulo de plan de prueba, casos de prueba, prueba Andamios, y

los datos de las pruebas son importantes para almacenar.

Gestión de la información. Un administrador puede necesitar información

sobre el módulo de programación y presupuesto.

Las dificultades de ejecución. En muchos casos, el arquitecto Tienen una

cierta estrategia de implementación en mente para un Módulo o puede

saber de las limitaciones que la aplicación Debe seguir. Esta información es

privada para el modulo y por lo tanto no aparecerá, por ejemplo, en el

Interfaz del módulo.

Construcción. Una vista del módulo puede proporcionar un modelo para el código fuente y

el almacén de datos.

Análisis. Dos técnicas de análisis son importantes requisitos trazabilidad y análisis de

impacto. Debido módulos partición del sistema, debería ser posible para determinar cómo

los requisitos funcionales de un sistema están soportadas por responsabilidades del

módulo.

¿Que módulos son para vistas?

Comunicación. Una vista módulo puede ser utilizado para explicar el funcionalidad del

sistema para alguien no familiarizado con el sistema.

Por otro lado, es difícil de utilizar los puntos de vista del módulo de hacer inferencias sobre

el comportamiento en tiempo de ejecución, ya que estos puntos de vista son sólo una

partición estática de las funciones del software.

Notaciones informales: Un número de notaciones puede ser

utilizado para presentar una vista módulo. Una notación informal

común utiliza cajas para representar los módulos, con diferentes

tipos de líneas entre ellos representan las relaciones.

Anotaciones para el modulo vistas

Lenguaje Unificado de Modelado

Notaciones de modelado de software, tales como UML, ofrecen una

variedad de construcciones que se pueden utilizar para representar

módulos.

UML fue creado originalmente para sistemas orientados a modelado

de objetos. Ahora se considera un lenguaje de modelado de propósito

general

LENGUAJE UML

UML fue creado originalmente para sistemas orientados a

modelado de objetos. Ahora se considera un lenguaje de modelado

de propósito general. Como en consecuencia, los elementos y las

relaciones UML son genéricas, es decir, no son específicos de las

tecnologías y plataformas de aplicación.

Una matriz de estructura de dependencias de (DSM) gestión de

soluciones de documento es una tabla que muestra módulos como

los encabezados de columna y fila y dependencias como las

celdas de la tabla. El DSM está construido como una matriz

cuadrada

Si se usan correctamente, los estereotipos hacen sus diagramas

UML más expresivo. El UML especificados proporciona una serie

de estereotipos estándar, pero se puede también crear uno

propio.

Diagrama Entidad-Relación

Un diagrama de entidad-relación (ERD) es una notación

específicamente utilizado para el modelado de datos. Se

muestra las entidades de datos que requieren una

representación en el sistema y sus relaciones. Estas

relaciones pueden ser de uno a uno, uno-a-muchos o

muchos-a-muchos.

Los módulos se refieren a la manera en que el software de un sistema esdescompuesto en unidades manejables de responsabilidades, que es una delas formas importantes de la estructura del sistema.

Los módulos están relacionados entre sí por las formas de es-parte-de, depende-de, y es-una relación.

Esperar a tener al menos una vista del módulo en el paquete dedocumentación.

Usted no debe depender de un nombre de módulo para definir lasfuncionalidades del módulo: utilizar la responsabilidad propia.

Módulo de interfaz Documento (s) para establecer el papel de un módulo en elsistema.

Gracias por su

atencion