Descargar la presentación
La descarga está en progreso. Por favor, espere
1
(c) P. Gomez-Gil, INAOEP. 20091 DISEÑO DE SOFTWARE 2ª. parte NOTAS DEL CURSO Ingeniería de Software I DRA. MARIA DEL PILAR GÓMEZ GIL INAOEP Versión:18-11-2009
2
(c) P. Gomez-Gil, INAOEP. 20092 Otros aspectos de diseño: Descripción de estructuras y bases de datos Los archivos y estructuras de datos son componentes fundamentales en el diseño, por lo que deben especificarse claramente y sin ambigüedad. La metodología utilizada para la descripción depende del diseño escogido en los datos
3
(c) P. Gomez-Gil, INAOEP. 20093 Documentación interna del Código El listado de los programas fuentes, ya sea impreso o en digital forma parte de la documentación del software. Los programas fuente deben estar documentados internamente por medio de comentarios. Se sugieren los siguientes lineamientos: (continúa)
4
(c) P. Gomez-Gil, INAOEP. 20094 Documentación interna del Código (cont.) En la parte superior de cada archivo de código fuente escribir un comentario inicial que incluya: Nombre del Proyecto Nombre de los programadores Nombre físico del archivo Breve descripción del objetivo del programa Fecha de codificación Fecha de última modificación (continúa)
5
(c) P. Gomez-Gil, INAOEP. 20095 Documentación interna del Código (cont.) Utilizar nombres mnemónicos para las variables y procedimientos. Incluir un comentarios descriptivo de las variables principales Describir el objetivo de cada procedimiento, así como el significado de sus parámetros de paso Documentar cualquier parte del programa que se considere necesaria para entender el funcionamiento de éste. Evitar comentarios inútiles o redundantes. Indentar el código a fin de facilitar su lectura.
6
(c) P. Gomez-Gil, INAOEP. 20096 Documentación interna del Código (cont.) Se sugiere almacenar los programas en media digital debidamente etiquetada con al menos la siguiente información: - Nombre del sistema - Nombre del responsable - Fecha - Plataforma de desarrollo - Plataforma de ejecución - Número del dispositivos de almacenamiento (en caso de existir varios) y total de éstos
7
7 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e copyright © 1996, 2001 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited. This presentation, slides, or hardcopy may NOT be used for short courses, industry seminars, or consulting purposes.
8
8 Chapter 14 Architectural Design copyright © 1996, 2001 R.S. Pressman & Associates, Inc. Corresponde al capítulo 10 en la versión 6 (2005) Del libro de texto
9
9 Why Architecture? The architecture is not the operational software. Rather, it is a representation that enables a software engineer to: (1) analyze the effectiveness of the design in meeting its stated requirements, (2) consider architectural alternatives at a stage when making design changes is still relatively easy, and (3) reduce the risks associated with the construction of the software. copyright © 1996, 2001 R.S. Pressman & Associates, Inc.
10
10 Data Design refine data objects and develop a set of data abstractions implement data object attributes as one or more data structures review data structures to ensure that appropriate relationships have been established simplify data structures as required copyright © 1996, 2001 R.S. Pressman & Associates, Inc.
11
11 Data Design—Component Level 1. The systematic analysis principles applied to function and behavior should also be applied to data. 2. All data structures and the operations to be performed on each should be identified. 3. A data dictionary should be established and used to define both data and program design. 4. Low level data design decisions should be deferred until late in the design process. 5. The representation of data structure should be known only to those modules that must make direct use of the data contained within the structure. 6. A library of useful data structures and the operations that may be applied to them should be developed. 7. A software design and programming language should support the specification and realization of abstract data types. copyright © 1996, 2001 R.S. Pressman & Associates, Inc.
12
12 Architectural Styles Data-centered architectures Data flow architectures Call and return architectures Object-oriented architectures Layered architectures Each style describes a system category that encompasses: (1) a set of components (e.g., a database, computational modules) that perform a function required by a system, (2) a set of connectors that enable “communication, coordination and cooperation” among components, (3) constraints that define how components can be integrated to form the system, and (4) semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts. copyright © 1996, 2001 R.S. Pressman & Associates, Inc.
13
13 Data-Centered Architecture copyright © 1996, 2001 R.S. Pressman & Associates, Inc.
14
14 Data Flow Architecture copyright © 1996, 2001 R.S. Pressman & Associates, Inc.
15
15 Call and Return Architecture copyright © 1996, 2001 R.S. Pressman & Associates, Inc.
16
16 Layered Architecture copyright © 1996, 2001 R.S. Pressman & Associates, Inc.
17
17 Analyzing Architectural Design 1. Collect scenarios. 2. Elicit requirements, constraints, and environment description. 3. Describe the architectural styles/patterns that have been chosen to address the scenarios and requirements: module view module view process view process view data flow view data flow view 4. Evaluate quality attributes by considered each attribute in isolation. 5. Identify the sensitivity of quality attributes to various architectural attributes for a specific architectural style. 6. Critique candidate architectures (developed in step 3) using the sensitivity analysis conducted in step 5. copyright © 1996, 2001 R.S. Pressman & Associates, Inc.
Presentaciones similares
