Transcript Ing. Soft 2
Ingeniería Software II
Universidad Politécnica de Honduras Ing. R. Fernández
Software: Introducción
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.
Características
Se Desarrolla (No se Fabrica en sentido Clasico) No se Estropea (No es Susceptible a los males del Entorno) Se Construye a Medida.
Aplicaciones del Software
• • • • • • • • 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
Ingeniería Software un Enfoque Practico, Pressman Ed 5, Cap I
Ocurre Como Consecuencia de un Proceso Llamado Ingeniería de Sistemas
Ingeniería de Sistemas Cap. 6
Ingeniería Software (IS)
Elementos
Ingeniería Procesos + Ingeniería de Productos
Analiza
Ayudan a dar Orden a Sistemas Basados en Computadoras
Ingeniería Software un Enfoque Practico, Pressman Ed 6, Cap 6
Diseña
Resultado
Organiza Producto Servicio Tecnologia
6.1 Sistemas Basados en Computadoras
Conjunto de Elementos que están organizados para cumplir una meta predefinida al procesar información
Hardware Personas Bases de Datos
Sistema
Para Propósitos de Estudio
Abarca: IN+IP
Ing. de Negocios Ing. de Productos Una Característica complicada de los sistemas basados en computadoras es que tal vez constituyen un macro elemento de un sistema mayor.
Software Elementos del Sistema
Se Combinan De Varias Maneras
Procedimientos
Transforman la Información 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
Ingeniería Software un Enfoque Practico, Pressman Ed 6, Cap 6
• • • •
6.2 La Jerarquía de la Ingeniería de Sistemas 6.2.1 Modelado del Sistema 6.2.2 Simulación del Sistema Modelado del Sistema Definir Procesos Representar Comportamiento Definen modo explicito de entradas y salidas (Exógenas y Endógenas) Representan todas las uniones
• • • • •
Considerar Algunas Restricciones Supuestos Simplificaciones Limitaciones Restricciones Preferencias Ingeniería Software un Enfoque Practico, Pressman Ed 6, Cap 6
6.3 Ing. Procesos de Negocios: Una Visión Global La Meta de la IPN es: Definir arquitecturas que permitan que un negocio utilice información de manera efectiva.
La IPN es un enfoque que crea un plan general para implementar la arquitectura de computo.
• • •
Arquitectura de Datos Arquitectura de Aplicaciones Infraestructura de Tecnologia
Analizar y Diseñar Dentro del contexto de los objetivos Y metas de negocios
Ingeniería Software un Enfoque Practico, Pressman Ed 6, Cap 6
6.4 Ing. De Producto: Una Visión Global La Meta de la Ing. de Producto es: Traducir el deseo del cliente, de una serie de capacidades definidas, a un producto del trabajo.
Debe Crear una: Arquitectura y Estructura Basada en:
Software Hardware Datos (BDD) Personas
Ingeniería Software un Enfoque Practico, Pressman Ed 6, Cap 6
Ing. De Requisitos
Como 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.
Validación de Requisitos Identificación de Requisitos Modelado del Sistema Especificación de Requisitos
Ingeniería Software un Enfoque Practico, Pressman Ed 5, Cap 10
Análisis y Negociación de Requisitos
6.5 Modelado del Sistema
Todos 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 Proceso Entrada Funciones y Proceso De Control Mantenimiento y Autocomprobación
Ingeniería Software un Enfoque Practico, Pressman Ed 6, Cap 6
Proceso Salida
8. Modelado del Análisis
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.
8.1 Análisis de Requisitos
•
8.1.1 Filosofía y Objetivos Generales
El modelo de análisis debe cumplir tres objetivos primarios:
Describe lo que requiere el cliente
•
Establecer una base para creación de un diseño de software la
•
Definir un conjunto de requisitos que puedan validarse una vez construido el software.
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.
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.
Entrada y Salida para el Análisis de Dominio Fuentes del Conocimiento Del Dominio Literatura Técnica Aplicaciones Existentes Sondeos a los Clientes Recomendación Experta Requisitos Actuales - Futuros Análisis de Dominio Taxonomía de Clase Estándar de Reutilización Modelos Funcionales Lenguajes de Dominio Modelo De Análisis De Dominio
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.
Enfoques de Modelado del Análisis Elementos Basados en Escenarios:
Casos de Usos, Textos, Diagramas de Actividad, Diagramas de Carril
Elementos de Comportamiento:
Diagramas de Estado, Diagramas de Secuencias.
Modelo de Análisis
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.
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.
Marca
Lexus BMW Wolvagen
Modelo
LS400 X5 Jetta
# Id
1132343 123567 156328
Tipo
Sedan Camioneta Sedan
Color
Rojo Negra Azul
Propietario
RSP AF2 REF
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.
8.3 Conceptos del modelado de datos 8.3.3 Relaciones: Los objetos están conectados entre si de muchas maneras.
Ejemplo:
8.3 Conceptos del modelado de datos 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 uno 2. De uno a muchos 3. De muchos a muchos Ejemplo:
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.
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
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.
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.
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.
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.
CLIENTE Numero de cuenta Cedula Nombres Apellidos Teléfono Dirección ingresar_tarjeta( ) ingresar_clave( ) ingresar_monto( ) retirar_dinero( ) revisar_cuenta( ) retirar_tarjeta( ) retirar_comprobante( )
Modelo de Clase-Responsabilidad Colaborador(CRC)
El modelado clases.
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
Modelo de Clase-Responsabilidad Colaborador(CRC) CRC: se puede extener en las diferentes categorías:
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 trabajo ” “ unidad de desde el inicio hasta el final.gh
Modelo de Clase-Responsabilidad Colaborador(CRC) 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.
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 .
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.
Modelos de Comportamiento Diagrama de Secuencia: representa el comportamiento al describir la forma en que las clases se mueven de estado a estado.