Software Modelling

Juan Carlos Olivares Rojas

MSN: juancarlosolivares@hotmail.comjcolivar@itmorelia.edu.mx

http://antares.itmorelia.edu.mx/~jcolivar/@jcolivares

Social Network: Facebook, LinkedIn. Hi5

• ¿Qué es un software?

• De acuerdo al std. IEEE 729: “Es el conjunto de los programas de cómputo, procedimientos, reglas, documentación y datos asociados que forman parte de las operaciones de un sistema de computación”.

• Existen diversos tipos de software: gestión, tiempo real, empotrado, etc.

Software

• Es la primera fase creativa del desarrollo de proyectos. Se compone de lo qué es análisis y diseño.

• El modelado parte de lo que es la Ingeniería de Requerimientos y devuelve un modelo que puede ser construido (implantable a través de lenguajes de programación).

Modelado

• ¿Qué es un modelo?

• Un modelo es una representación de la realidad. No sólo se modela software sino prácticamente cualquier actividad.

• ¿Para qué se modela?

• Para resolver un problema más fácilmente

Modelado

• El análisis es “descomponer” un problema o cosa para ver como trabaja. Por lo tanto el modelado parte del problema.

• El planteamiento del problema lleva al análisis del negocio (contexto de la aplicación) a la Ingeniería de Requerimientos y posteriormente a la construcción de la solución propuesta (diseño).

Modelado

• En análisis estructurado se utiliza la técnica de Diagrama de Flujo para especificar procesos, Diagrama Entidad-Relación para especificar datos y diagramas de transición de estados para control. Diagramas de contexto o de Flujo de Datos Nivel 1 para indicar arquitectura.

• Para el modelado de datos se recomienda definir todos los objetos (entidades) y definir sus atributos.

Modelado

• El diseño es la primera parte del desarrollo de cualquier proyecto.

• Etimológicamente significa componer, por lo que se obtiene la solución que habrá de implantarse.

• Todas las cosas siempre tienen primero una creación mental.

Modelado

• El diseño en proyectos informáticos presenta cuatro apartados: datos, arquitectura, interfaz y procedimientos.

• El diseño de datos se encarga de transformar el modelo de información obtenido en el proceso de análisis en estructuras de datos. Se pueden utilizar diagramas entidad-relación pero especificados a mayor detalle.

Modelado

• El diseño arquitectónico tiene la finalidad de comprobar las relaciones con los diferentes módulos o macrorequisitos del sistema (subsistemas).

• El diseño de interfaz define como se comunica el software consigo mismo y hacia el exterior.

Modelado

• El diseño procedimental o basado en componentes consiste en la traducción de cada uno de los elementos obtenidos en la especificación de procesos, datos y transición hacia elementos implantables a través de computadoras.

Modelado

• El proceso de diseño sirve de base para la codificación del sistema. Se deben seguir algunas recomendaciones para su mejor desarrollo como las siguientes:

• Se deben especificar todos los elementos explícitos e implícitos del modelo de análisis.

Modelado

• El diseño deber servir de guía para que cual integrante del proyecto pueda construir y entender el software.

• El diseño debe de dar una completa idea de lo que es el software.

• El diseño debe presentar uniformidad e integración. Se deben definir reglas y estilos que deben seguir los miembros del equipo.

Modelado

• El diseño debe estar estructurado, de tal forma que permita cambios.

• El diseño no es escribir código, ni codificar es diseñar.

• Al diseñar se deben tomar en cuenta Factores de Calidad Externos (velocidad, Fiabilidad, utilidad) y Factores de Calidad Interno (abstracción, refinamiento, modularidad).

Modelado

• UML (Unified Modelling Language), lenguaje de modelado unificado. Fue desarrollado en 1997 al fusionar las metodologías de Ivar Jacobson, Jame Rumbaugh y Grady Booch.

• Es un lenguaje visual, su premisa básica radica en que una imagen vale más que 1,000 líneas de código.

Modelado

• Es el lenguaje estándar para modelar proyectos de software.

• La versión más actual del lenguaje es la 2.2 definida en 2009.

• Los métodos que se fusionaron para crear UML fueron OMT (Rumbaugh), Objectory (Jacobson) y el método Booch.

Modelado

• Casi el 80% de los proyectos de software fallan.

• Nadie construye una casa sin un plano.

• Actualmente existen muchas herramientas que auxilian el proceso de modelado como Visio, ArgoUML, Rational Rose, Together, etc.

Modelado

• Los modelos deben ser más baratos que la realidad.

• Es más fácil para una persona entender un diagrama que las líneas de código fuente de un programa.

• Los diagramas al igual que el texto consumen tiempo.

Modelado

• Se deben construir modelos que sean representativos para que sean útiles (imaginense hacer un documento de 100 hojas que nadie va a leeer)

• UML define varios tipos de diagramas los cuales pueden ser extensibles.

Modelado

Diagramas UML 2.2

• ¿Cuántos diagramas debo crear? No existe una respuesta específica.

• ¿Debo hacer diagramas de todo tipo? No, sólo se deben utilizar los diagramas que mejor reflejen el modelado de la problemáticao.

Modelado

• ¿Qué tan grande debe de ser un diagrama? Entre más grande sea un diagrama mayor es la confusión. Se deben realizar diagramas bien detallados, pero no tan detallados.

• ¿Cuánto texto debe complementar el modelo? Entre menos texto mejor, son como los comentarios del código fuente: pocos pero claros.

Modelado

• Algunas recomendaciones para el modelado de software son:

• No tenga a los programadores esperando los modelos.

• Trabajar de una macrovista a una microvista(enfoque Top-Down).

Modelado

• Se debe documentar en forma económica.

• Si es obvio no se debe de modelar.

• Hacer hincapié en la especialización.

• Utilizar patrones de diseño.

• Refactorizar.

Modelado

• Somos instaladores de una red local de computadoras y necesitamos saber donde están las tuberías en un edificio, el problema radica en que no hay un plano de las instalaciones del edificio…

• ¿Qué hacemos?• Romper la pared haber donde está la

tubería• Pasar un cable guía y ver donde sale• Solución decente: probador de tonos•

Requerimientos

• Todo se debe a problemas de comunicación…

• De entendimiento del problema (Implicación de los Usuarios, Apoyo de los directivos, Enunciado claro de los requisitos)

• De la visión del proyecto entre los clientes, usuarios y desarrolladores (Falta de información por parte de los usuarios, Especificaciones y requisitos incompletos, Especificaciones y requisitos cambiantes)

Requerimientos

• “La parte más difícil de construir de un sistema de software es precisamente saber QUÉ construir. Ninguna otra parte del trabajo conceptual es tan difícil como establecer los requerimientos técnicos detallados, incluyendo todas las interfaces con gente, máquinas y otros sistemas. Ninguna otra parte del trabajo afecta tanto el sistema si es hecha mal. Ninguna otra parte es más difícil de rectificar después” (Brooks)

Requerimientos

• De acuerdo al IEEE:

• Una condición o capacidad que un usuario necesita para resolver un problema o lograr un objetivo

• Una condición o capacidad que debe tener un sistema o un componente de un sistema para satisfacer un contrato, una norma, una especificación u otro documento formal.

Requerimientos

• La Ingeniería de Requerimientos es un conjunto de actividades en las cuáles, utilizando técnicas y herramientas, se analiza un problema y se concluye con la especificación de una solución (Ortas 1997).

• SRS (Software Requirement Specification) es un documento que contiene una descripción completa de qué hará el software sin describir cómo lo hará.

Requerimientos

• Entre más tarde detecte un error en el ciclo de vida del desarrollo de software, más caro costará repararlo.

Requerimientos

• Los errores hechos en la especificación de requerimientos son típicamente hechos incorrectos, omisiones, inconsistencias y ambigüedades

Requerimientos

• Los errores de requerimientos pueden ser detectados

Requerimientos

• Proceso de Ingeniería de RequerimientosRequerimientos

Participación del usuario

Estudio defactibilidad

Obtención yanálisis

Especificación Validación

Requerimientosdel usuario

Retroalimentacióndel usuario

Especificaciónde requerimientos

Modelos a validarpor el usuario

Modelo derequerimientosConocimiento

Necesidad de másconocimiento

Resultado devalidación

Requerimientos

Verificación deRequerimientos

Comprensióndel dominio

Recolección de Requerimientos

Priorización

Resolución de conflictos

Clasificación

Especificación deRequerimientos

DOCUMENTO DEREQUERIMIENTOS

PROCESO DE OBTENCIONY ANÁLISIS DE

REQUERIMIENTOS

Herramientas de RequerimientosHerramienta Extracció

nAnálisis

Especificación

Validación

Entrevistas y Cuestionario X

Sistemas existentes X X

Grabaciones video/audio X X

Brainstorming X X

Arqueología de doctos. X X

Aprendiz X

Observación X

Prototipos X X

FODA X

Diagrama de pescado X X X

Glosario X X X X

Casos de uso X X X X

Casa de Calidad QFD X

Checklist X X

Diagramas FD X X

Modelos de clases X X

Diagramas de estado (transición, actividades, RP)

X X

• Los requerimientos pueden ser funcionales (explícitos) o no funcionales (implícitos).

• Las características que deben perseguir los requerimientos son: necesario, conciso, completo, consistente, no ambiguo, verificable.

• Los problemas que presenta la Ingeniería de Requerimientos son tres:

Requerimientos

1. Los requerimientos no son obvios y provienen de muchas fuentes.

2. Son difíciles de expresar en palabras.

3. Un requerimiento puede cambiar en el transcurso del proyecto.

• El éxito de la obtención de requerimientos consiste en ponernos en los zapatos de nuestros clientes y no desarrollando a nuestros gustos.

Requerimientos

• Definen los límites del sistema

• Si los límites son ambiguos…

Requerimientos

• Los requerimientos deben de ser probados

Requerimientos

V-modelRequerimientos

Análisis

Diseño del Sistema

Diseño deObjetos

Codificación

Pruebas deUnidad

Pruebas deIntegración

Pruebas deAceptación

Men

or d

etal

leM

ayor

det

alle

build system validate system

is validated by

• Los métodos ágiles promueven el reuso de requerimientos. Si se trata de proyectos similares, se tendrán algunos requerimientos esenciales.

• Al centrarse más en las personas que en los procesos manejan mejor los cambios. De hecho un principio fundamental es !bienvenidos los cambios!

• La entrevista es el principal método de IR

Requerimientos en Met. Ágiles

• La priorización de los requerimientos es fundamental.

• Al existir reuniones frecuentemente (generalmente diaria) los requerimientos se van especificando frecuentemente siendo más acertados.

• No hay una trazabilidad tan marcada de los requerimientos y se hace una aproxima tardía (lazy). Entre más tarde, mejor.

Requerimientos en Met. Ágiles

• Aunque se centran más en el software que funciona a la documentación exhaustiva, si se documenta.

• Primero el software, después la documentación (aunque previamente han existido “borradores”).

• Principal principio: satisfacer al cliente a través de la entrega temprana y continua de software de valor.

Requerimientos en Met. Ágiles

• Debe haber siempre comunicación con el cliente e interactuar cara a cara (por eso no es tan bueno los cuestionarios).

• Aunque es un mito (de acuerdo con Lean Software Development) que as especificaciones tempranas reducen los errores ayudan bastante. No se debe considerar un desperdicio los requerimientos como tal vez lo sea una lista de bugs.

Requerimientos en Met. Ágiles

Requerimientos en Met. Ágiles

Requerimientos en Met. Ágiles

• Talleres de Requerimientos

• Lluvia de ideas

• Documento de visión

• Trazabilidad de requerimientos (implementación y pruebas)

• Gestión de la Configuración del Software

Requerimientos en Met. Ágiles

• RFP (Request for Proposal) es un documento en donde se específica el desarrollo de un sistema o el uso de un bien o servicio.

• Las solicitudes de propuestas deben formularse en lenguaje claro, terminología integral y formato estandarizado para facilitar la comprensión de los objetivos de los sistemas de la organización, por parte de los proveedores.

RFP/ Solicitud de Propuesta

• ¿Quiénes participan durante el proceso de Ingeniería de Requerimientos?

• Los supervisores del contrato• Los clientes y los usuarios• Los gerentes del negocio• Los diseñadores• Los verificadores

• En metodologías a´giles como Scrum se llaman Product Owners.

Stakeholders en Ing. Req.

• Los requerimientos deben escribirse de modo que sean significativos no sólo para los clientes, sino también para los diseñadores que integran el equipo de desarrollo.

Documentación de Req.

Definición de Requerimientos

Especificación de Requerimientos

Clases de documentos

de Requerimiento

s

Requerimientos de los usuarios

Requerimientos de usuario Requerimientos del sistema

LENGUAJE COTIDIANO LENGUAJE TÉCNICO

¿Qué requerimientos hay?

Grados de UML• Como sketch

• Como “blueprint”

• Como lenguaje de programación

Arquitectura 4+1 Vistas• En esta arquitectura de desarrollo de

software un producto a ser desarrollado tiene 4 puntos de vistas dependiendo del tipo de personal involucrado en el proyecto.

• Las 4 vistas se concentran en el desarrollo de escenarios que describen el análisis y los requerimientos del sistema.

Arquitectura 4+1 Vistas

Vista Lógica Vista de Desarrollo

Vista del Proceso Vista Física

Escenarios

Arquitectos Desarrolladores

Integradores Ingenieros deInfraestructura

Analistas Del

Negocio

Vista Lógica• Se maneja el estilo arquitectónico de la

aplicación:– Orientado a objeto– Basado en Componentes– Basado en servicios

• La implementación de esta vista utiliza generalmente patrones arquitectónicos como el MVC (Modelo-Vista-Controlador)

Vista de Desarrollo• Define los módulos de software ha ser

construidos.

• Se deben definir con claridad las interfaces de E/S de los módulos.

• La modularización de componentes depende del estilo arquitectónico seleccionado en la vista lógica

Vista Física• Mapea los componentes de software con

el hardware (fase de despliegue)

• Un buen diseño promueve la flexibilidad de mapear componentes de software con diferentes confiuraciones físicas dentro de las diferentes fases del ciclo de vida del software.

• La vista de proceso está relacionada en la forma de darle seguimiento, control y dirección a las etapas del desarrollo del producto.

Escenarios• Son abstracciones de los requerimientos

más importantes.

• Están estrechamente relacionados con el uso de casos de uso

• La vista del escenario es redundante entre las otras vistas.

• Otra forma de obtener requerimientos es a través de diagramas de casos de uso dentro de UML

• Se recomienda utilizar diagramas de caso de uso ya que nos dan los macrorequisitos de la aplicación. Cada caso de uso debe ser especificado de manera correcta.

• Lista de capacidades que debe brindar el sistema.

Casos de Uso

• Los elementos principales son los actores y los casos de usos que en conjunto forman un escenarios.

• Se deben establecer prioridades para las capacidades del sistema.

• ¿Cuál es la diferencia entre un editor de textos como Notepad y Word?

• Objetivos primarios: crear, guardar e imprimir documentos de texto.

Casos de Uso

• Objetivos secundarios: guardar el archivo en formato HTML, RTF y PDF.

• Los diagramas de uso sirven para mostrar detalles de implementación del sistema a usuarios finales.

• Los estereotipos agregan detalles a una relación.

• Los estereotipos más utilizados son: inclusión y de extensión.

Casos de Uso

• Muchas herramientas no implantan UML al 100% existen muchos problemas de compatibilidad entre dichas herramientas. XMI es la descripción de un diagrama UML en XML el cual utilizan varias herramientas para exportar diagramas.

• Las notas ayudan ha aclarar los diagramas. Las notas deben ser como elementos taquigráficos.

Casos de Uso

Casos de Uso

Casos de Uso

Casos de Uso¿Quién es un actor y quién no? ¿Qué es un caso de uso y qué no?

¿Un caso de uso es un DFD?

• Obtener los requerimientos del Problema del Poker Planning

Requerimientos

¿Preguntas?