Conceptos Fundamentales en Ingeniería de Software y Diseño de Sistemas

Ingeniería de Requisitos

Requisitos No Funcionales

• Un requisito no funcional define una restricción o una cualidad del sistema (ej. rendimiento, seguridad, usabilidad).

Ciclo de Vida del Proyecto de Software

• Un proyecto de software se considera terminado cuando el sistema es retirado o descontinuado de su uso.

Definición de Requisito (IEEE)

• Según el IEEE, un requisito es una condición o capacidad que un usuario necesita para resolver un problema o lograr un objetivo, o una condición o capacidad que debe poseer un sistema o componente para satisfacer un contrato, estándar, especificación u otro documento formalmente impuesto.

Prototipado en Ingeniería de Software

• El prototipado facilita la extracción de requisitos, el ensayo de soluciones y la mitigación de partes arriesgadas del proyecto.

Casos de Uso

• El término "casos de uso" puede referirse tanto a un objetivo específico que un actor desea lograr con el sistema, como a la secuencia de interacciones para conseguir dicho objetivo.

Negociación de Requisitos

• Los requisitos deben negociarse con los stakeholders (interesados) para resolver conflictos, priorizar y alcanzar un consenso sobre el alcance del sistema.

Especificación de Requisitos

• En la especificación de requisitos, no es correcto expresar opcionalidad a menos que exista un atributo explícito asignado para tal fin.

Mitos en la Especificación de Requisitos

• Es falso afirmar que es posible detectar absolutamente todos los defectos durante la fase de especificación de requisitos.

Propiedades de Transacciones (Atomicidad)

• En sistemas transaccionales, la atomicidad asegura que una operación (como una inserción) se complete por completo o no se realice en absoluto, manteniendo la integridad de los datos.

Documentación de Requisitos

• Un documento puede describir requisitos no funcionales, como el rendimiento, la seguridad o la usabilidad del sistema.

Identificadores de Requisitos

• El orden lógico de los requisitos suele tener poca relación con la asignación cronológica de sus identificadores numéricos.

Fases del Ciclo de Vida de un Requisito

• Las fases comunes en el ciclo de vida de un requisito incluyen: creación, propuesta, validación, verificación e implementación.

Modelado Orientado a Objetos (UML)

Clase vs. Tipo de Datos (Datatype)

• Una clase representa una plantilla para objetos con estado y comportamiento, pudiendo ser simple o estructurada. Un tipo de dato (datatype) es un descriptor de valores (ej. entero, cadena, fecha), que puede ser primitivo o estructurado, pero no tiene identidad ni comportamiento propio como una clase.

Modelado de Conceptos de Dominio

• Algunos conceptos del dominio pueden ser mejor representados como reglas de negocio en lugar de clases u objetos, especialmente aquellos que definen restricciones o políticas operativas.

Comparación de Instancias: Clases vs. Tipos de Datos

• La comparación de dos instancias de una clase se realiza por referencia (comparando sus direcciones de memoria), mientras que la comparación de dos instancias de un tipo de dato se realiza por valor (comparando sus contenidos).

Generalización Múltiple (Herencia Múltiple)

• Una generalización múltiple ocurre cuando una clase especializa (hereda de) varias superclases simultáneamente.

Multiplicidad en Asociaciones

• En el modelado de asociaciones (ej. entre Servicio, Comida, Bebida), la multiplicidad define cuántas instancias de una clase pueden estar relacionadas con instancias de otra. Es crucial definirla correctamente para reflejar las restricciones del dominio.

Principio de Sustitución de Liskov (LSP)

• Según el Principio de Sustitución de Liskov (Barbara Liskov), todos los objetos de una subclase deben poder ser sustituidos por objetos de su superclase sin alterar la corrección del programa.

Diagramas de Clases vs. Diagramas de Objetos

• Mientras que los diagramas de clases capturan y especifican el vocabulario del sistema (clases, atributos, relaciones), los diagramas de objetos muestran instancias específicas de esas clases en un momento dado, representando una instantánea del sistema.

Asociaciones Reflexivas

• Una asociación reflexiva es aquella en la que una clase se relaciona consigo misma. La afirmación de que "es un tipo especial de asociación que representa una relación todo-parte transitiva y asimétrica" NO corresponde a una característica exclusiva de una asociación reflexiva, sino más bien a una composición o agregación.

Relaciones de Composición/Agregación

• La relación entre "Plato" e "Ingredientes" es un ejemplo común de composición o agregación, donde un plato "contiene" o "está compuesto de" ingredientes.

Modelado de Información y Operaciones

• En un nivel de abstracción elevado, los modelos de información suelen omitir las operaciones de las clases, centrándose en la estructura y las relaciones de los datos más que en el comportamiento o la implementación.

Concepto de Modelo en Ingeniería

• Un modelo es una simplificación de la realidad que se utiliza para comprender mejor un sistema o un dominio, permitiendo el análisis y la comunicación.

Ingeniería Directa e Inversa

• La ingeniería inversa implica la creación de un modelo a partir de un sistema existente (código). La ingeniería directa (o forward engineering) consiste en generar código a partir de un modelo de diseño.

Interfaces en Programación

• Una interfaz es un conjunto de operaciones que define un contrato, ofreciendo un servicio coherente sin especificar su implementación.

Arquitectura de Sistemas

Componentes en la Vista de Desarrollo

• En la vista de desarrollo del modelo 4+1, un componente representa una unidad de código fuente que encapsula el estado y el comportamiento de una parte específica de la implementación del sistema.

Invariantes de Clase

• Una invariante de clase es una condición que debe ser verdadera para todas las instancias de una clase en todos los momentos observables (antes y después de la ejecución de cualquier operación pública), garantizando la consistencia del objeto.

Diseño por Contrato: Nombres y Semántica

• En la especificación formal de un contrato, los nombres están relacionados con la semántica, pero no la expresan completamente ni la garantizan por sí solos.

Diseño por Contrato y Generalización

• En el diseño por contrato aplicado a la generalización, es falso que la precondición en una operación de la clase hija pueda ser más restrictiva que en la clase madre. Por el contrario, debe ser igual o más débil (menos restrictiva) para mantener la sustituibilidad.

Extensibilidad en Arquitectura de Sistemas

• Diseñar la arquitectura de un sistema favoreciendo la extensibilidad implica facilitar la adición de nuevas características, a menudo a costa de una mayor complejidad en el diseño inicial.

Relaciones entre Vistas del Modelo 4+1

• En el modelo 4+1, la vista de proceso y la vista de desarrollo influyen en la vista física, donde los requisitos no funcionales son cruciales para la implementación y el despliegue del sistema.

Vista de Desarrollo en el Modelo 4+1

• La vista de desarrollo en el modelo 4+1 describe la descomposición del sistema desde la perspectiva del programador, utilizando principalmente diagramas de componentes para organizar el código fuente.