Engenharia de Software II

Presentación del tema: "Engenharia de Software II"— Transcripción de la presentación:

1 Engenharia de Software II http://engenhariasoftwareisutic.wordpress.com

2 Recordando…

3 MODELOS ANÁLISIS DISEÑO ¿Qué funciones? ¿Cómo funciona? Representar el ¿qué? Representar el ¿cómo? Modelación

4 Cria uma representação ou modelo de software que proporciona detalhes a respeito das estruturas dos dados, as arquitecturas, as interfaces e os componentes do software que são necessários para implementar o sistema.. Desenho de Software

5 Permite fazer uma ponte entre a linguagem do cliente e a linguagem que entendem os desenvolvedores. Permite fazer efetiva a arquitectura candidata, contribuindo a conseguir uma arquitectura estável e sólida. Permite criar um plano mais próximo ao que posteriormente deve se escrever como código. Papel do Desenho de Software

6 ¿Principios del diseño de software?

7 1.O desenho deve ser rastreable até o modelo de análise. 2.Sempre se deve considerar a arquitectura do sistema que se vai construir. 3.O desenho de dados é tão importante como o desenho de funções de processamento. 4.As interfaces (internas e externas) devem desenhar-se com cuidado. Princípos do Desenho de Software

8 5.O desenho de interface do utente deve ajustar às necessidades do utente final. 6.O desenho a nível de componentes deve ser independente do modo funcional. 7.Os componentes devem estar juntados entre se em forma mínima e vinculados com o ambiente externo. Princípos do Desenho de Software

9 8.As representações do desenho (modelos) devem ser facilmente compreensíveis. 9.O desenho deve desenvolver-se de maneira iterativa. Na cada iteração o desenhador deve procurar a maior simplicidad.

10 ¿Cómo construir un modelo del diseño?

11 Conferencia 4: Diseño de Software Orientado a Objetos

12 1.Diseño orientado a objetos.  Marco conceptual.  Patrones de diseño  Paquetes y subsistemas. Contéudos

13 Identificar los elementos básicos necesarios para diseñar la estructura de un software orientado a objetos. Objectivo

14 Relación M. Análisis- M. Diseño Desenho do Software

15 Relación entre los elementos estructurales más importantes del software, los estilos arquitectónicos y patrones que pueden usarse para satisfacer los requisitos del sistema y las restricciones de implementación. Diseño arquitectónico

16  Entidad que tiene un estado y un conjunto definido de operaciones que operan en ese estado. El estado es representado como un conjunto de atributos del objeto. (…)  Son creados de acuerdo a una definición de clases de objetos. Sommerville Objeto

17 Un sistema OO está compuesto por objetos que interactúan, los cuales mantienen su estado local y proveen operaciones sobre su estado. Diseño OO

18 El proceso de diseño OO comprende el diseño de clases de objetos y las relaciones entre estas clases. Las clases definen los objetos del sistema y sus interacciones. Diseño OO

19 Transforma los modelos del análisis y clases, en las clases del diseño y estructuras de datos que se requieren para implementar el Software. Pressman Cap 9 Diseño de datos/clases

20 1.Los objetos son entidades autónomas. 2.Los objetos son independientes. 3.Los cambios en un objeto no deben 4.afectar a los demás objetos. 5.Los objetos son unidades reutilizables. Principios de diseño OO Iguales principios que la Programación Orientada a Objetos (POO)

21 Representa una abstracción de una o varias clases en la implementación del sistema, dependiendo del lenguaje de programación. Las clases definen los objetos, con los cuales se implementan los casos de uso. Las particularidades del lenguaje de programación influyen en el diseño de las clases. Diagramas de clases del diseño.

22 Contiene :  Clases.  Interfaces.  Colaboraciones.  Relaciones de dependencia, generalización y asociación Diagramas de clases del diseño

23 Marco Conceptual Modelo Conceptual Classes conceptuaisAtributosAsociaçõesMultiplicidadeAnotações

24 Classes conceptuais Elementos lógicos ou físicos que ajudam a entender o problema, é parte da linguagem utilizada pelo cliente e geralmente se nomeia como substantivo. Representam-se com o símbolo de uma classe. Ej: Cliente, casa

25 Atributos Informação que caracteriza à classe. Mostra-se no segundo compartimento da representação da classe. Ej: nome, idade.

26 Asociações Relações lógicas ou físicas que existem entre 2 conceitos.

27 Multiplicidade Número de instâncias de um conceito relacionadas com o outro conceito.

28 Anotações Nomenclatura que caracteriza ou descreve um determinado conceito..

29 Se desea implementar un software que tiene como objetivos la gestión de la información relacionada con los partidos de Futbol. Caso de Estudio

30 Un equipo está compuesto por 11 futbolistas. Los futbolistas tienen nombre. Un partido lo juegan 2 equipos En un partido cada equipo puede meter goles Un gol se mete en un momento determinado. Datos importantes

31 Diagramas de clases del diseño.

32 Para la realización de estos diagramas se utilizan patrones. La aplicación de patrones de diseño garantiza un diseño de sistema consistente y bien estructurado.

33 Un patrón de diseño es una descripción de clases y objetos comunicándose entre sí adaptada para resolver un problema de diseño general en un contexto particular. PATRONES DE DISEÑO.

34  Un solución estándar para un problema común de programación.  Una técnica para flexibilizar el código haciéndolo satisfacer ciertos criterios.  Una manera más práctica de describir ciertos aspectos de la organización de un programa.  Conexiones entre componentes de programas.  La forma de un diagrama de objeto o de un modelo de objeto. UN PATRONES DE DISEÑO ES:

35  Son soluciones concretas.  Se utilizan en situaciones frecuentes.  Favorecen la reutilización de código.  El uso de un patrón no se refleja en el código.  Es difícil reutilizar la implementación de un patrón. CARACTERÍSTICAS

36 Se desean las siguientes funcionalidades: – Insertar goles al partido – De qué equipo es un jugador determinado – El listado de futbolistas por equipos – La cantidad de goles de un partido. – El futbolista que metió determinado gol – La cantidad de goles que ha metido cada equipo – La cantidad de goles de cada futbolista, con el momento exacto en que lo ha metido y contra quien.

37 ¿Cómo asignar las responsabilidades en las clases?

38 Patrones de los principios generales para asignar responsabilidades. (General Responsibility Assignment Software Patterns) GRASP

39 Este patrón ayuda a responder la pregunta de qué clase debe ser la responsable de crear nuevos objetos (instancias de alguna clase). GRASP

40 GRASP. TIPOS  Creador  Experto  Alta cohesión  Bajo acoplamiento  Controlador

41 El equipo: el gol lo mete un equipo, pero el equipo no sabe contra quién juega. El futbolista: el gol lo ha metido él, pero el jugador no sabe cuándo lo ha metido, ni contra quien. El partido: el partido sería el creador perfecto, ya que el sabe que equipos están jugando, que jugadores están en el campo, etc. GRASP. Creador. Ejemplo

42 CREATOR

43 Asignar una responsabilidad al experto en información: la clase que cuenta con la información necesaria para cumplir la responsabilidad. Experto

44 Se desean las siguientes funcionalidades: – Insertar goles al partido – De qué equipo es un jugador determinado – El listado de futbolistas por equipos – La cantidad de goles de un partido. – El futbolista que metió determinado gol – La cantidad de goles que ha metido cada equipo – La cantidad de goles de cada futbolista, con el momento exacto en que lo ha metido y contra quien.

45 Experto

46 Asigna la responsabilidad del manejo de los eventos del sistema a una clase. Controlador

47 GRASP. Controlador. Ejemplo CRONTROLADOR

48 Alta Cohesión y Bajo Acomplamiento Asignar responsabilidades a las clases que trabajen sobre una misma área de la aplicación y que no tengan mucha complejidad, evitando así que una clase sea la única responsable de muchas tareas en áreas funcionales muy heterogéneas.

49 Alta Cohesión y Bajo Acomplamiento Se asignan las responsabilidades de forma tal que cada clase se comunique con el menor número de clases, minimizando el nivel de dependencia.

50 Alta cohesión- Bajo acoplamiento

51 ¿Cuántas clases puede tener un proyecto? ¿Cómo se pueden organizar para lograr mejor entendimiento?

52 Paquete de Diseño Estructura el modelo de diseño dividiéndolo en partes más pequeñas.

53 Paquete de Diseño Contiene:  Clases  Interfaces.  Colaboraciones.  Relaciones de dependencia, generalización y asociación.

54 Subsistema de Diseño Parte del modelo de diseño que encapsula comportamientos, expone un conjunto de interfaces, y empaqueta otros elementos del modelo.

55 Interfaz (No UI) Elemento del modelo que define una entrada de comportamientos ofrecidas por un elemento clasificador del modelo. Provee una única y bien definida entrada de operaciones

56 Relaciones Subsistema-Interfaz

57 ¿Cómo se diseña la estructura de un sistema? ¿Qué elementos permiten el modelado del diseño? ¿Qué representa cada uno? ¿Son útiles los patrones? Conclusiones

58 Sommerville, I.; 2005. “Ingeniería de Software‖, Parte III. Capítulo 14. Pressman, Roger S.; 2007. ‖Ingeniería de software. Un enfoque práctico‖. 6ta Edición. Capítulo 9 Jacobson, Ivar y otros; 2004. El Lenguaje Unificado de Modelado de Software: Manual de referencia. Editorial Félix Varela, Ciudad de La Habana. Bibliografía

59 Engenharia de Software II http://engenhariasoftwareisutic.wordpress.com