Transcript Clase modelo

Software Modelling
Juan Carlos Olivares Rojas
MSN: [email protected]
[email protected]
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 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.
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
son
típicamente
hechos
incorrectos, omisiones, inconsistencias y
ambigüedades
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álisis
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
Diagramas de estado (transición, actividades, RP)
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
• Gestión de la Configuración del Software
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 Product Owners.
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 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.
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
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
¿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?