Software Modelling Juan Carlos Olivares Rojas MSN: juancarlosolivares@hotmail.com jcolivar@itmorelia.edu.mx http://antares.itmorelia.edu.mx/~jcolivar/ @jcolivares Social Network: Facebook, LinkedIn. Hi5
Software
• ¿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.
Modelado
• 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 proyectos de software.
para
modelar
• 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.
Diagramas UML 2.2
Modelado
• ¿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 microvista(enfoque Top-Down).
a
una
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.
Requerimientos
• 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 incorrectos, ambigüedades
son
omisiones,
típicamente
hechos
inconsistencias
y
Requerimientos
• Los errores de requerimientos pueden ser detectados
Requerimientos
• Proceso de Ingeniería de Requerimientos Participación del usuario
Retroalimentación del usuario
Requerimientos del usuario
Especificación de requerimientos
Estudio de factibilidad
Obtención y análisis
Modelos a validar por el usuario
Especificación Conocimiento
Necesidad de más conocimiento
Validación Modelo de requerimientos
Resultado de validación
Requerimientos Especificación de Requerimientos Verificación de Requerimientos
Comprensión del dominio
Recolección de Requerimientos
DOCUMENTO DE REQUERIMIENTOS
Priorización
Resolución de conflictos
Clasificación
PROCESO DE OBTENCION Y ANÁLISIS DE REQUERIMIENTOS
Herramientas de Requerimientos
Herramienta
Extracción
Análisi s
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
FODA
Especificaci ón
Validación
X X
Diagrama de pescado
X
X
X
Glosario
X
X
X
X
Casos de uso
X
X
X
X
Casa de Calidad QFD Checklist
X X
X
Diagramas FD
X
X
Modelos de clases
X
X
Requerimientos
• 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 Análisis
Pruebas de Aceptación
is validated by
Diseño del Sistema
Pruebas de Integración
Diseño de Objetos
Mayor detalle
Menor detalle
V-model
Pruebas de Unidad
Codificación
build system
validate system
Requerimientos en Met. Ágiles
• 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 (implementación y pruebas)
requerimientos
RFP/ Solicitud de Propuesta
• 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.
Stakeholders en Ing. Req.
• ¿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
Documentación de 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.
Clases de documentos de Requerimientos
Definición de Requerimientos Especificación de Requerimientos
Requerimientos de los usuarios
Requerimientos de usuario
LENGUAJE COTIDIANO
Requerimientos del sistema
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 Arquitectos
Desarrolladores Vista L贸gica
Vista de Desarrollo
Escenarios
Vista del Proceso Integradores
Analistas Del Negocio Vista F铆sica Ingenieros de Infraestructura
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 construidos.
de
software
ha
ser
• 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.
Casos de Uso
• 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
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 ¿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?
Requerimientos
• Obtener los requerimientos del Problema del Poker Planning
多Preguntas?