Especificación de requisitos de desempeño en el diagrama de clases
La especificación de requisitos no funcionales en sistemas software, ha presentado múltiples retos a académicos investigadores interesados en el tema. Las cada vez más crecientes exigencias de los sistemas en atributos catalogados, dentro de los que se denominan requisitos no funcionales, como desem...
| Autor Principal: | Serna, Sergio; Centro de Investigación Instituto Tecnológico Metropolitano,Medellín |
|---|---|
| Otros Autores: | Arango, Fernando; Escuela de Sistemas Facultad de Minas, Universidad Nacional, Medellín |
| Formato: | info:eu-repo/semantics/article |
| Idioma: | spa |
| Publicado: |
Universidad Santo Tomás. Seccional Bucaramanga
2010
|
| Materias: | |
| Acceso en línea: |
http://revistas.ustabuca.edu.co/index.php/ITECKNE/article/view/356 |
| Etiquetas: |
Agregar Etiqueta
Sin Etiquetas, Sea el primero en etiquetar este registro!
|
| Sumario: |
La especificación de requisitos no funcionales en sistemas software, ha presentado múltiples retos a académicos investigadores interesados en el tema. Las cada vez más crecientes exigencias de los sistemas en atributos catalogados, dentro de los que se denominan requisitos no funcionales, como desempeño, seguridad, escalabilidad, entre otros, ha permitido diversos enfoques a la hora de construir los planos software del sistema deseado por el cliente. Este trabajo se enmarca dentro de la especificación formal de requisitos temporales no funcionales, utilizando el lenguaje de modelado unificado para la construcción de los planos software. El trabajo no trata sobre requisitos funcionales o no funcionales que no están relacionados con tiempo. La especificación se hace sólo sobre diagramas de clase UML, y se apoya en métodos existentes durante las primeras etapas de desarrollo, lo que le permite elicitar los requisitos e ir llevándolos de manera consistente a través de todos los diagramas del modelo, hasta llegar a un nuevo diagrama de clases. Este nuevo diagrama de clases relaciona elementos del modelo con los del metamodelo, logrando una mayor expresividad y permitiendo tomar decisiones de implementación que antes no era posible en esta etapa del desarrollo. Para lograr esto, es necesario realizar una variante a la semántica del diagrama de clases, permitiendo relacionar metaclases que antes no estaban relacionadas. Igualmente, se introduce una nueva simbología para expresar la nueva metarelación presente en el diagrama de clases. |
|---|