(c) P. Gomez-Gil, INAOEP. 2009 1

DISEÑO DE SOFTWARE2ª. parte

NOTAS DEL CURSO

Ingeniería de Software IDRA. MARIA DEL PILAR GÓMEZ GIL

INAOEP

Versión:18-11-2009

(c) P. Gomez-Gil, INAOEP. 2009 2

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

(c) P. Gomez-Gil, INAOEP. 2009 3

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)

(c) P. Gomez-Gil, INAOEP. 2009 4

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)

(c) P. Gomez-Gil, INAOEP. 2009 5

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.

(c) P. Gomez-Gil, INAOEP. 2009 6

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

Supplementary Slides forSoftware Engineering:A Practitioner's Approach, 5/e

copyright © 1996, 2001

R.S. Pressman & Associates, Inc.

For University Use OnlyMay 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 forshort courses, industry seminars, or consulting purposes.

8

Chapter 14Architectural Design

copyright © 1996, 2001 R.S. Pressman & Associates, Inc.

Correspondeal capítulo 10 en la versión 6 (2005)Del libro de texto

9

Why Architecture?

The architecture is not the operational software. The architecture is not the operational software. Rather, it is a representation that enables a software Rather, it is a representation that enables a software engineer to: engineer to:

(1) analyze the effectiveness of the design in meeting (1) analyze the effectiveness of the design in meeting its stated requirements, its stated requirements,

(2) consider architectural alternatives at a stage when (2) consider architectural alternatives at a stage when making design changes is still relatively easy, and making design changes is still relatively easy, and

(3) reduce the risks associated with the construction of (3) reduce the risks associated with the construction of the software.the software.

copyright © 1996, 2001 R.S. Pressman & Associates, Inc.

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

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

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

Data-Centered Architecture

copyright © 1996, 2001 R.S. Pressman & Associates, Inc.

14

Data Flow Architecture

copyright © 1996, 2001 R.S. Pressman & Associates, Inc.

15

Call and Return Architecture

copyright © 1996, 2001 R.S. Pressman & Associates, Inc.

16

Layered Architecture

copyright © 1996, 2001 R.S. Pressman & Associates, Inc.

17

Analyzing Architectural Design

1.1. Collect scenarios. Collect scenarios. 2. Elicit requirements, constraints, and environment 2. Elicit requirements, constraints, and environment description. description. 3. Describe the architectural styles/patterns that have been 3. Describe the architectural styles/patterns that have been chosen to address the scenarios and requirements:chosen to address the scenarios and requirements:

• • module viewmodule view• • process viewprocess view• • data flow viewdata flow view

4. Evaluate quality attributes by considered each attribute in 4. Evaluate quality attributes by considered each attribute in isolation. isolation. 5. Identify the sensitivity of quality attributes to various 5. Identify the sensitivity of quality attributes to various architectural attributes for a specific architectural style. architectural attributes for a specific architectural style. 6. Critique candidate architectures (developed in step 3) 6. Critique candidate architectures (developed in step 3) using the sensitivity analysis conducted in step 5.using the sensitivity analysis conducted in step 5.

copyright © 1996, 2001 R.S. Pressman & Associates, Inc.