LOS FUNDAMENTOS DE LA ESPECIFICACIÓN

1. LOS FUNDAMENTOS DE LA ESPECIFICACIÓN Carlos Mario Zapata J. Teoría y Métodos de la Ingeniería de Software

2. ENTREGABLE 3 1. Elaborar la especificación textual correspondiente a los diagramas del entregable 2 2. Identificar un subalfa y sus estados y elaborar las tarjetas correspondientes 3. Elaborar las tarjetas de nivel de competencia a tres competencias Teoría y Métodos de la Ingeniería de Software

3. ENTREGABLE 3 4. Adicionar dinamismo a los diferentes diagramas en visio, así: - Al dar doble click a una práctica en el diagrama (1) se debería activar un hipervínculo a la primera página de descripción de la práctica - Al dar doble click a un alfa en el diagrama (2) se debería desplegar la tarjeta del estado en que queda el alfa al elaborar el producto de trabajo - Al dar doble click a un producto de trabajo en el diagrama (2) o en el (4) se debería desplegar la tarjeta de ese producto de trabajo - Al dar doble click a un rol en el diagrama (2) o en el (4) se debería desplegar la tarjeta de ese rol - Al dar doble click a una actividad en el diagrama (3) se debería desplegar la tarjeta de esa actividad - Al dar doble click a una fase en el diagrama (3) se debería desplegar la tarjeta de esa fase - Al dar doble click a una competencia en el diagrama (4) se debería desplegar la tarjeta de esa competencia Teoría y Métodos de la Ingeniería de Software

4. La Esencia Teoría y Métodos de la Ingeniería de Software

5. Estructura del metamodelo del lenguaje Teoría y Métodos de la Ingeniería de Software

6. Fundamentos del lenguaje Teoría y Métodos de la Ingeniería de Software 6

7. Alfas y productos de trabajo en el lenguaje Teoría y Métodos de la Ingeniería de Software

8. Espacios de actividad y actividades en el lenguaje Teoría y Métodos de la Ingeniería de Software

9. Competencias en el lenguaje Teoría y Métodos de la Ingeniería de Software

10. Vistas en el lenguaje Teoría y Métodos de la Ingeniería de Software

11. Diagrama de objetos práctica Teoría y Métodos de la Ingeniería de Software

12. Diagrama de objetos otra práctica Teoría y Métodos de la Ingeniería de Software

13. Diagrama de objetos composición de prácticas Teoría y Métodos de la Ingeniería de Software

14. Especificación textual alfas Descripción del alfa en lenguaje natural alphaRequirements { "What the software system must do to address the opportunity and satisfy the stakeholder community." state Conceived {"The need for a new system has been agreed."} state Bounded {"The theme and extent of the new system is clear."} state Coherent {"The requirements provide a coherent description of the essential characteristics of the new system."} state Sufficient {"The requirements describe a system that is acceptable to the stakeholders."} state Satisfactory {"The requirements that have been addressed partially satisfy the need in a way that is acceptable to the stakeholders."} state Fulfilled {"The requirements that have been addressed fully satisfy the need."} transition Conceived -> Bounded transition Bounded -> Coherent transition Coherent -> Sufficient transition Sufficient -> Satisfactory transition Satisfactory -> Fulfilled } Estados con nombre y descripción Transiciones entre nombres de estados Teoría y Métodos de la Ingeniería de Software

15. Asociaciones alfa-subalfa Los subalfas deberían tener multiplicidades(pero la especificación no lo incluye) SoftwareSystem contains 1 Architecture SoftwareSystem contains 1..N Components SoftwareSystem –“fulfills“--> Requirements Alternativa: SoftwareSystem relates to Requirements as “fulfills“ Asociaciones dirigidas entre alfas Sintaxis más común, pero más difícil de leer Teoría y Métodos de la Ingeniería de Software

16. Productos de trabajo Si se asocian recursos, acá se colocan workProduct DeveloperTest: "..." with levels { level Sketched {"..."} sufficient level Implemented {"..."} } Teoría y Métodos de la Ingeniería de Software

17. Espacios de actividad y actividades Criterio de terminación (estado de alfa). Puede ser un conjunto activitySpaceSpecifyTheSystem { targets{Requirements.Sufficient} inputAlphas {Requirements} } activityFindActorsAndUseCases { targets{UseCaseModel.ActorsAndCasesFound} output {UseCaseModel} } Se permite un conjunto de alfas Criterio de terminación (estado de producto de trabajo). Puede ser un conjunto input/output para productos de trabajoinputAlpha/outputAlpha para alfas Teoría y Métodos de la Ingeniería de Software

18. Prácticas Multiplicidad otra vez Manifiesto de los alfas practiceUseCasePractice { Requirementsmanifestsby 1 UseCaseModel doSpecifyTheSystemby {FindActorsAndUseCases,SpecifyUseCaseModel} } practiceUserStoryPractice { Requirementsmanifestsby 1..N UserStory,UserAcceptanceTest doSpecifyTheSystemby {WriteUserStories,WriteUserAcceptanceTests} foreachUserStory } Referencia al espacio de actividad Conjunto de referencias a actividades Manifiesto de actividades Acá se permite un conjunto de referencias a productos de trabajo Iteraciones(El lenguaje de especificación aún no las incluye) Teoría y Métodos de la Ingeniería de Software

19. Más sobre prácticas Práctica mínima sin actividades ni espacios de actividad(El lenguaje aún no la incluye) practice SomePractice { do reach {Requirements.Bounded} do reach {Requiremens.Sufficient,SoftwareSystem.Demonstrable} } practice SomeOtherPractice { do UnderstandTheNeed do SpecifyTheSystem do ShapeTheSystem do EnsureStakeholderSatisfaction } Algunos pasos anónimos para alcanzar algunos estados de los alfas (aún sin Manifiesto de los alfas) Práctica sin actividades y sin Manifiesto de los alfas, pero con espacios de actividad Teoría y Métodos de la Ingeniería de Software