Ingeniería Software II Universidad Politécnica de Honduras Ing. R. Fernández.

31
Ingeniería Software II Universidad Politécnica de Honduras Ing. R. Fernández

Transcript of Ingeniería Software II Universidad Politécnica de Honduras Ing. R. Fernández.

Page 1: Ingeniería Software II Universidad Politécnica de Honduras Ing. R. Fernández.

Ingeniería Software II

Universidad Politécnica de Honduras

Ing. R. Fernández

Page 2: Ingeniería Software II Universidad Politécnica de Honduras Ing. R. Fernández.

IntroducciónSoftwar

e:El Software de la computadora es el producto que diseñan y construyen los ingenieros de software. Abarca programas que se ejecutan dentro de una computadora de cualquier tamaño y arquitectura

EL Software es un elemento del sistema que es lógico, en lugar de físico. Por tanto el Software tiene unas características considerablemente distintas a las del hardware.

• Se Desarrolla (No se Fabrica en sentido Clasico)

• No se Estropea (No es Susceptible a los males del Entorno)

• Se Construye a Medida.

• Software de Sistemas• Software de Tiempo Real• Software de Gestion• Software de Ingenieria y

Cientifico• Software Empotrado• Software de Computadoras

Personales• Software Basado en Web• Software de Inteligencia Artificial

Características

Aplicaciones del Software

Ingeniería Software un Enfoque Practico, Pressman Ed 5, Cap I

Page 3: Ingeniería Software II Universidad Politécnica de Honduras Ing. R. Fernández.

Ingeniería Software (IS)

Ocurre Como Consecuencia de un Proceso Llamado Ingeniería de

Sistemas

Producto Servicio Tecnologi

a

Analiza

Diseña

Organiza

Ingeniería Software un Enfoque Practico, Pressman Ed 6, Cap 6

Ingeniería de Sistemas Cap. 6

Resultado

Elementos

Ingeniería Procesos+

Ingeniería de Productos

Ayudan a dar Orden a Sistemas Basados en Computadoras

Page 4: Ingeniería Software II Universidad Politécnica de Honduras Ing. R. Fernández.

Abarca: IN+IPIng. de Negocios Ing. de Productos

Elementos del

SistemaSoftware

Hardware

Personas

Bases de Datos

Procedimientos

Ingeniería Software un Enfoque Practico, Pressman Ed 6, Cap 6

6.1 Sistemas Basados en ComputadorasConjunto de

Elementos que están organizados para cumplir una

meta predefinida al procesar

informaciónSistemaPara Propósitos de Estudio Se

CombinanDe Varias Maneras

Transforman la Información

Una Característica complicada de los sistemas basados en computadoras es que tal vez constituyen un macro elemento de un sistema mayor.

Page 5: Ingeniería Software II Universidad Politécnica de Honduras Ing. R. Fernández.

Ingeniería Software un Enfoque Practico, Pressman Ed 6, Cap 6

6.2 La Jerarquía de la Ingeniería de Sistemas

Visión Global

• Se Examina el Dominio Entero del Negocio

Visión Del Dominio

• Dominio de Interés en Específicos

Visión del Elemento

• Elementos del Sistema (Información, Software, Hardware, Personas)

Visión Detallada

• Técnicas detalladas

Page 6: Ingeniería Software II Universidad Politécnica de Honduras Ing. R. Fernández.

Ingeniería Software un Enfoque Practico, Pressman Ed 6, Cap 6

6.2.1 Modelado del Sistema6.2.2 Simulación del Sistema

6.2 La Jerarquía de la Ingeniería de Sistemas

Modelado del Sistema

Considerar Algunas Restricciones

• Definir Procesos• Representar

Comportamiento• Definen modo

explicito de entradas y salidas (Exógenas y Endógenas)

• Representan todas las uniones

• Supuestos• Simplificaciones• Limitaciones• Restricciones• Preferencias

Page 7: Ingeniería Software II Universidad Politécnica de Honduras Ing. R. Fernández.

Ingeniería Software un Enfoque Practico, Pressman Ed 6, Cap 6

6.3 Ing. Procesos de Negocios: Una Visión GlobalLa Meta de la IPN es: Definir

arquitecturas que permitan que un negocio utilice información de manera efectiva.

• Arquitectura de Datos• Arquitectura de

Aplicaciones• Infraestructura de

Tecnologia

La IPN es un enfoque que crea un plan general para implementar la arquitectura de computo.

Analizar y Diseñar Dentro del contexto de los

objetivosY metas de negocios

Page 8: Ingeniería Software II Universidad Politécnica de Honduras Ing. R. Fernández.

Ingeniería Software un Enfoque Practico, Pressman Ed 6, Cap 6

6.4 Ing. De Producto: Una Visión GlobalLa Meta de la Ing. de Producto es:

Traducir el deseo del cliente, de una serie de capacidades definidas, a un producto del trabajo.

Software

Hardware

Datos (BDD)

Personas

Debe Crear una: Arquitectura y Estructura Basada en:

Page 9: Ingeniería Software II Universidad Politécnica de Honduras Ing. R. Fernández.

Ingeniería Software un Enfoque Practico, Pressman Ed 5, Cap 10

Ing. De RequisitosComo podemos asegurar que hemos especificado un sistema que

recoge las necesidades del cliente.No hay una respuesta segura a esta difícil pregunta, pero un solido proceso de ingeniería de requisitos es la mejor solución que disponemos.

Identificación de

Requisitos

Análisis y Negociació

n de Requisitos

Especificación de

Requisitos

Modelado del

Sistema

Validación de

Requisitos

Page 10: Ingeniería Software II Universidad Politécnica de Honduras Ing. R. Fernández.

Ingeniería Software un Enfoque Practico, Pressman Ed 6, Cap 6

6.5 Modelado del SistemaTodos los sistemas basados en computadoras pueden modelarse como una transformación de la información empleando una arquitectura tipo: Entrada, Proceso y Salida.

Hatley y Pirbhai incluyen dos características adicionales: • Procesamiento de la Interfaz de Usuario• Mantenimiento y Procesamiento de Autocomprobación

Proceso de Interfaz de Usuario

ProcesoEntrada

ProcesoSalida

Funciones y Proceso

De Control

Mantenimiento y

Autocomprobación

Page 11: Ingeniería Software II Universidad Politécnica de Honduras Ing. R. Fernández.

8. Modelado del Análisis

8.1 Análisis de Requisitos

El análisis de los requisitos genera la especificación de características operacionales de software.

Indica la Interfaz del software con otros elementos del sistema y establece las restricciones que tiene el software.

Permite al ingeniero de software construir elementos que representen escenarios del usuario, actividades funcionales, clases de problemas y sus relaciones.

La especificación de requisitos ofrecen al desarrollador y al cliente los medios para evaluar la calidad una vez construido el software.

Page 12: Ingeniería Software II Universidad Politécnica de Honduras Ing. R. Fernández.

8.1.1 Filosofía y Objetivos Generales

• Definir un conjunto de requisitos que puedan validarse una vez construido el software.

El modelo de análisis debe cumplir tres objetivos primarios:

• Describe lo que requiere el cliente

• Establecer una base para la creación de un diseño de software

Page 13: Ingeniería Software II Universidad Politécnica de Honduras Ing. R. Fernández.

8.1.2 Reglas prácticas para el Modelado de Análisis

• El modelo debe centrarse en los requisitos visibles dentro del problema o dominio de negocio.

• Cada elemento del modelo de analisis debe agregarce a un acuerdo general de los rquisitos del software y proporcionar una vision interna del dominio de informacion, fumcion y comportamiento del sistema.

• Se debe minimizar el acoplamiento de todo el sistema

• Se debe tener la seguridad de que el modelo de análisis proporciona valor a todos los interesados.

• El modelo debe mantenerse tan simple como sea posible.

Page 14: Ingeniería Software II Universidad Politécnica de Honduras Ing. R. Fernández.

8.1.3 Análisis del Dominio

El análisis del domino es la identificación, el análisis de requisitos comunes de un dominio especifico de aplicación para de manera típica reutilizarlo en múltiples proyectos. El Análisis de Dominio de aplicación especifica puede variar.

Taxonomía de Clase

Análisis de

Dominio

Aplicaciones Existentes

Sondeos a los Clientes

Recomendación Experta

Requisitos Actuales - Futuros

Literatura Técnica

Estándar de Reutilización

Modelos Funcionales

Lenguajes de Dominio

Fuentes del

ConocimientoDel

Dominio

Modelo De

AnálisisDe

Dominio

Entrada y Salida para el Análisis de Dominio

Page 15: Ingeniería Software II Universidad Politécnica de Honduras Ing. R. Fernández.

8.2 Enfoques de Modelado del Análisis

Análisis Estructurado:

Los Datos y el proceso que transforman los datos son entidades separadas.

Los objetos de datos se modelan en una forma que define sus atributos y relaciones.

Análisis Orientado a Objetos: Se centra en la definición de clases y en la manera en que éstas colaboran entre ellas para efectuar los requisitos del sistema.

Page 16: Ingeniería Software II Universidad Politécnica de Honduras Ing. R. Fernández.

Enfoques de Modelado del Análisis

Modelo de

Análisis

Elementos Basados en Escenarios:

Casos de Usos, Textos, Diagramas de

Actividad, Diagramas de

Carril

Elementos Orientados

al Flujo: Diagramas de Flujo de Datos, Diagramas de

Flujo de Control,

Narrativas de procesamiento

.

Elementos Basados en

Clases: Diagramas de

Clases, Paquete de Análisis,

Modelos CRC, Diagramas de Colaboración.

Elementos de Comportamie

nto: Diagramas de

Estado, Diagramas de

Secuencias.

Page 17: Ingeniería Software II Universidad Politécnica de Honduras Ing. R. Fernández.

8.3 Conceptos del modelado de datos

El modelado de datos es define todos los objetos de datos que se procesan dentro del sistema y las relaciones entre los objetos de datos.

8.3.1 Objetos de datos: Es una representación de casi cualquier información compuesta (se refiere a que tiene muchas propiedades o atributos diferentes) que el software debe entender. Ejemplo: auto, marca, modelo.

8.3.2Atributos: Los atributos definen las propiedades de un objeto de datos y toman una de las tres características diferentes: 1.Nombrar un ocurrencia(Entidad) del objeto de Datos. Describir la Ocurrencia 3. Hacer referencia a otra ocurrencia.

Marca Modelo # Id Tipo Color Propietario

Lexus LS400 1132343 Sedan Rojo RSP

BMW X5 123567 Camioneta Negra AF2

Wolvagen Jetta 156328 Sedan Azul REF

Page 18: Ingeniería Software II Universidad Politécnica de Honduras Ing. R. Fernández.

8.3.3 Relaciones:

Los objetos están conectados entre si de muchas maneras.

Ejemplo:

8.3 Conceptos del modelado de datos

Page 19: Ingeniería Software II Universidad Politécnica de Honduras Ing. R. Fernández.

8.3.4 Carnalidad: establece el número de objetos que pueden participar en una relación. Las relaciones pueden ser:

1. De uno a uno2. De uno a muchos3. De muchos a muchos

Ejemplo:

8.3 Conceptos del modelado de datos

Page 20: Ingeniería Software II Universidad Politécnica de Honduras Ing. R. Fernández.

8.4 Análisis Orientado a Objetos

El Objetivo es definir todas las clases relevantes(además de las relaciones y el comportamiento asociado con ellas) para el problema y que deben resolverse.

Esto se logra llevando a cabo algunas tareas:• Deben comunicarse los requisitos básicos del

usuario entre el cliente y el ingeniero de software.• Deben identificarse las clases, es decir, definir los

atributos y métodos.• Se define una jerarquía de clases.• Deben representarse las relaciones de objeto a

objeto.• Debe modelarse el comportamiento del objeto.• Las tareas 1 a 5 se vuelven a aplicar de manera

iterativa hasta que el modelo esté completo.

Page 21: Ingeniería Software II Universidad Politécnica de Honduras Ing. R. Fernández.

8.5 Modelado basado en Escenarios

El modelado de análisis con UML comienza con la creación de escenarios en la forma de casos de uso, diagramas de actividad y diagramas de carril.

8.5.1 Estructura o Diagrama de casos de

uso:Un caso de uso especifica la manera en la que los actores interactúan con el sistema en un conjunto específico de circunstancias. El desarrollo de una serie de casos de uso se inicia realizando una lista de las funciones o actividades que ejerce un actor específico.

Acceso a la cámara de vigilancia vía internet

Configurar Paramentos del Sistema Hogar Seguro

Configurar Alarma

Cámaras

Page 22: Ingeniería Software II Universidad Politécnica de Honduras Ing. R. Fernández.

8.5.2 Diagrama de Actividades

Complementa el caso de uso al proporcionar una representación grafica del flujo de interacción dentro de un escenario específico.

Page 23: Ingeniería Software II Universidad Politécnica de Honduras Ing. R. Fernández.

8.5.3 Diagrama de Carril

Es una variación útil del diagrama de actividad, ya que permite al modelador la representación del flujo de actividades descritas por el caso de uso y al mismo tiempo indicar que actor o clases de análisis tiene la responsabilidad de la acción descrita mediante un rectángulo de actividad.

Page 24: Ingeniería Software II Universidad Politécnica de Honduras Ing. R. Fernández.

8.6 Modelo Orientado al Flujo

Tiene una visión del sistema del tipo entrada-proceso-salida. Los objetos de datos fluyen hacia el interior del software, se transforman mediante elementos de procesamiento y los objetos de datos resultantes fluyen al exterior del software.

Page 25: Ingeniería Software II Universidad Politécnica de Honduras Ing. R. Fernández.

8.7 Modelado basado en clases

Una clase orientada a objetos encapsula atributos de los datos pero también incorpora las operaciones que manipulan los datos implicados por dichos atributos. Las clases se manifiestan en la siguiente forma: entidades externas, sucesos o eventos, cosas, papeles o roles, unidades organizacionales, sitios y estructuras.

CLIENTENumero de cuentaCedulaNombresApellidosTeléfonoDireccióningresar_tarjeta( )ingresar_clave( )ingresar_monto( )retirar_dinero( )revisar_cuenta( )retirar_tarjeta( )retirar_comprobante( )

Page 26: Ingeniería Software II Universidad Politécnica de Honduras Ing. R. Fernández.

Modelo de Clase-Responsabilidad-Colaborador(CRC)

El modelado de Clase-Responsabilidad-Colaborador (CRC) proporciona un medio simple para identificar y organizar las clases relevantes para los requisitos del sistema o producto. Un modelo CRC es una colección de tarjetas índices estándar que representan clases. El objeto es desarrollar una representación organizada de las clases.

Page 27: Ingeniería Software II Universidad Politécnica de Honduras Ing. R. Fernández.

CRC: se puede extener en las diferentes categorías:

Modelo de Clase-Responsabilidad-Colaborador(CRC)

1. Clases de entidad: llamadas clases de modelo o negocios, se extraen de manera directa del enunciado del problema.

2. Clases de frontera: se utilizan para crear la interfaz que el usuario ve y con la cual interactúa cuando se utiliza el software.

3. Clases de controlador: manejan una “unidad de trabajo” desde el inicio hasta el final.gh

Page 28: Ingeniería Software II Universidad Politécnica de Honduras Ing. R. Fernández.

Responsabilidad:

Son los atributos y las operaciones relevantes para la clase.

Colaboradores:

Son aquellas clases que se requieren para que una clase reciba la información necesaria para completar una responsabilidad.

Agregación:

Son las subclases que forman parte de una clase, se conectan a través de una relación de tipo es parte de.

Modelo de Clase-Responsabilidad-Colaborador(CRC)

Page 29: Ingeniería Software II Universidad Politécnica de Honduras Ing. R. Fernández.

Asociaciones y Dependencias

Asociaciones: son las relaciones entre clases.

Dependencia: en el contexto de las clases va ligada a las operaciones, indicando que una clase utiliza otra como argumento en la signatura de una operación .

Page 30: Ingeniería Software II Universidad Politécnica de Honduras Ing. R. Fernández.

Modelos de Comportamiento

El modelo de comportamiento indica la forma en que el software responderá a los eventos o estímulos externos. 

• Diagrama de estado: representa el comportamiento de las clases cuando el sistema realiza sus funciones.

Page 31: Ingeniería Software II Universidad Politécnica de Honduras Ing. R. Fernández.

Diagrama de Secuencia: representa el comportamiento al describir la forma en que las clases se mueven de estado a estado.

Modelos de Comportamiento