Ingeniería de software II - Parte 4

  • 2,058 views
Uploaded on

Material académico de consulta. Ingeniería de Software - Universidad de Medellín (Colombia)

Material académico de consulta. Ingeniería de Software - Universidad de Medellín (Colombia)

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
2,058
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Parte 1.3Proceso de Desarrollo Unificado FLUJOS DE TRABAJO – UP - Flujo de Diseño Material académico preparado por: Ph.D, Marta Silvia Tabares B. Fecha última actualización 4-Sep-2011
  • 2. Ingeniería de Software II(mapa conceptual de tópicos de conocimiento) Material Preparado por MARTA SILVIA TABARES B. UdeM
  • 3. Bibliografía• Roger Pressman. Ingeniería del Software (6ª ED.). Mcgraw-hill / Interamericana.• Alan Dennis, Barbara Haley Wixom and David Tegarden. Systems Analysis and Design with UML Version 2.0 - An Object Oriented Approach, Second Edition. John Wiley & Sons © 2005.• Ivar Jacobson, Grady Booch, James Rumbaugh. El Proceso Unificado de Desarrollo de Software. Adisson Wesley. 2001.• Arlow, J., and Neustad, I. UML 2 and the Unified Process: Practical Object-Oriented Analysis and Design (2nd Edition). Addison-Wesley Object Technology Series. 2005.• OMG-UML. Unified Modeling Language: Superstructure. version 2.0, formal/05-07- 04. 2005.• Simon Bennett, Stee McRobb, y Ray Farmer. Análisis y Diseño Orientado a Objetos del Sistema, Usando UML. McGraw-Hill, 2006. Material Preparado por MARTA SILVIA TABARES B. UdeM
  • 4. Proceso Unificado Flujo de Diseño PRODUCTOS Dcto. de visión refinado Dcto. de evaluación del riesgo Fases refinado Disciplinas Inicio Elaboración Construcción Transición Modelo de requisitos No- funcionales Requisitos Modelo de casos de uso Análisis arquitectónicamente significativos (Diagramas de Actividades, Diagramas de Comunicación) Diseño Modelo de ClasesImplementación Modelo de componentes Pruebas Esquema de la base de datos Iteraciones I1 I2 I3 I4 I5 I6 In+1 In+2 Im Im+1 Preliminares Prototipos definitivos Arquitectura ejecutable Modelo de Pruebas Material Preparado por MARTA SILVIA TABARES B. UdeM
  • 5. Definición de Componente de Software (1)• Un componente representa una parte modular de un sistema que encapsula sus contenidos y cuya manifestación es reemplazable dentro de su ambiente [UML].• Un componente actúa como una caja negra cuyo comportamiento externo está completamente definido por sus interfaces requeridas y proporcionadas. Material Preparado por MARTA SILVIA Flujo de Diseño UP TABARES B. UdeM
  • 6. Definición de Componente de Software (2)• En la programación orientada a objetos y la tecnología de objetos distribuidos, un COMPONENTE es un conjunto de clases e interfaces que realizan los requisitos funcionales y no funcionales con una API externa reusable.• Componentes podrían ejecutarse en un ambiente de red distribuido para formar una aplicación en red. Material Preparado por MARTA SILVIA Flujo de Diseño UP TABARES B. UdeM
  • 7. Diseño de Componentes (1) Principios básicos: PrimeroPrincipio “abierto-cerrado”Un componente debe estar abierto a extensiones perodebe estar cerrado para modificaciones. El/la diseñador(a)debe especificar el componente de manera que puedeextenderse sin necesidad de hacer modificaciones internasal código. Material Preparado por MARTA SILVIA Flujo de Diseño UP TABARES B. UdeM
  • 8. Diseño de Componentes (2) Principios básicos: SegundoPrincipio “de substitución de Liskov”Las subclases deben ser sustituibles por sus clases bases.Cualquier clase derivada de una clase base debe cumplircon cualquier contrato implícito de la clase base conrespecto a los componentes que la usan.Un “contrato” es una precondición que debe serverdadera antes de que el componente use la clase base,y una post-condición debe ser verdadera después de queel componente usa la clase base. Material Preparado por MARTA SILVIA TABARES B. UdeM Flujo de Diseño UP
  • 9. Diseño de Componentes (3) Principios básicos: TerceroPrincipio “de Dependencia de Inversión”Se debe depender de abstracciones, no de eventosconcretos. Material Preparado por MARTA SILVIA Flujo de Diseño UP TABARES B. UdeM
  • 10. Diseño de Componentes (5) Principios básicos: QuintoPrincipio “de segregación de interfaces”Varias interfaces dependientes del cliente son mejorque una interfaz de propósito general Material Preparado por MARTA SILVIA Flujo de Diseño UP TABARES B. UdeM
  • 11. Diseño de Componentes (6) Principios de EMPAQUETADOPrincipio “de equivalencia de liberación yreuso”La granularidad del reuso es la granularidad deliberación. Esto significa que se deben agruparclases reusables en paquetes que se puedanadministrar y controlar cuando una nuevaversión se genere. Material Preparado por MARTA SILVIA Flujo de Diseño UP TABARES B. UdeM
  • 12. Diseño de Componentes (7) Principios de EMPAQUETADOPrincipio “de agrupamiento común”Las clases que cambian al mismo tiempodeben agruparse Material Preparado por MARTA SILVIA Flujo de Diseño UP TABARES B. UdeM
  • 13. Diseño de Componentes (8) Principios de EMPAQUETADOPrincipio “de reuso común”Las clases que no se reusan al mismo tiempono deben agruparse Material Preparado por MARTA SILVIA Flujo de Diseño UP TABARES B. UdeM
  • 14. Diseño de Componentes (9)Tipos de Componentes y Marcos de Trabajo Componente CAJA NEGRA Dispositivo o un sistema o un objeto cuando se ve sobre todo en términos de sus características de la entrada y de salida. Casi cualquier cosa se pudo referir de vez en cuando como caja negra: a transistor, algoritmo, seres humanos, Internet.Marcos de trabajo (framework) de Caja NegraSu instanciación se realiza por medio de composición y delegación, enlugar de utilizar la herencia. Los puntos de entrada se definen por mediode interfaces que deben implementar los componentes que extiendan elmarco. Material Preparado por MARTA SILVIA Flujo de Diseño UP TABARES B. UdeM
  • 15. Diseño de Componentes (10) Tipos de Componentes y Marcos de Trabajo Componente CAJA BLANCA Un sistema donde están disponibles los componentes o la lógica interna para la inspección (tal como a software libre/abra la fuente programa) cuál se conoce a veces como a caja blanca, una caja de cristal, o una caja clara.Marcos de trabajo (framework) de Caja BlancaQue se extienden mediante herencia, concretamente mediante laimplementación de las clases y métodos abstractos definidos como puntosde entrada. Se tiene acceso al código del marco y se permite reutilizar lafuncionalidad de sus clases mediante herencia yredefinición de métodos. Material Preparado por MARTA SILVIA TABARES B. UdeM Flujo de Diseño UP
  • 16. Diseño de Componentes (11)Tipos de Componentes y Marcos de TrabajoMarcos de trabajo (framework) Caja de Cristal Admiten la inspección de su estructura e implementación, pero no su modificación ni extensión, excepto en los puntos de entrada.Marcos de trabajo (framework) Caja de CristalLos puntos de entrada no son simplemente métodos abstractos, de los quese declara meramente su signatura, sino que se definen por medio de unlenguaje de especficación de alto nivel los requisitos que deben cumplirse ala hora de implementarse. Material Preparado por MARTA SILVIA Flujo de Diseño UP TABARES B. UdeM
  • 17. Pasos para el Diseño de Componentes (1)1. Identifique todas las clases de diseño que correspondan al dominio del problema2. Identifique todas las clases de diseño que correspondan al dominio de la infraestructura (GUI, sistemas operativos, administración de datos etc.)3. Elabore todas las clases que no provienen de clases reusadas a) Especifique detalles de los mensajes entre clases que colaboran b) Identifique las interfaces de cada componente c) Elabore atributos y defina tipos de datos y estructuras de datos requeridas para implementarlas d) Describa el flujo de procesamiento de cada componente en detalle. Material Preparado por MARTA SILVIA Flujo de Diseño UP TABARES B. UdeM
  • 18. Pasos para el Diseño de Componentes (2)4. Describa fuentes de datos persistentes (bases de datos y archivos) e identifique las clases requeridas para manipularlos5. Desarrolle y elabore representaciones del comportamiento de una clase o componente (diagramas de estados)6. Elabore diagramas de liberación (deployment) para dar detalles adicionales de implementación7. Revise cada representación de diseño de los componentes y siempre considere alternativas Material Preparado por MARTA SILVIA Flujo de Diseño UP TABARES B. UdeM
  • 19. Modelos de Componentes (1) Material Preparado por MARTA SILVIA Flujo de Diseño UP TABARES B. UdeM
  • 20. Interfaz (1)• Una interfaz especifica un nombrado conjunto de características públicas.• Para identificar una interfaz se debe separar la especificación de funcionalidad de su implementación por un clasificador tal como una clase o un subsistema.• Una interfaz NO puede se puede instanciar. Esta sólo declara un contrato que puede ser realizado por cero o muchos clasificadores. Flujo de Diseño UP Material Preparado por MARTA SILVIA TABARES B. UdeM
  • 21. Interfaz (2) Interfaz Específica Clasificador realizadorOperación Debe tener una operación con el misma identidad (firma) y semántica.Atributo Debe tener operaciones públicas para get y set los valores del atributo.Asociación Debe tener una asociación al clasificador destino, esto si una interfaz especifica una asociación a otra interfaz, el clasificador implementador de estas interfaces debe tener una asociación entre ellas.Restricción (constraint) Debe soportar restricciónEstereotipo (stereotype) Tiene un estereotipoValor etiquetado (tagged value) Tiene un valor etiquetadoProtocolo Debe realizar el protocolo definido p.ej., en una máquina de estado finito. Material Preparado por MARTA SILVIA TABARES B. UdeM Flujo de Diseño UP
  • 22. Interfaz (2)El conjunto de interfaces realizadas por un clasificador se conoce comosu interfaz PROPORCIONADA (provided).Cuando un clasificador requiere una o más interfaces para su operación,estas se conocen como sus interfaces REQUERIDAS (required) Notación “Lollipop” Interface (pirulí ☺) Relación de Realización Libro CD Material Preparado por MARTA SILVIA Flujo de Diseño UP TABARES B. UdeM
  • 23. Interfaz (4)Material Preparado por MARTA SILVIA TABARES B. UdeM Flujo de Diseño UP
  • 24. Interfaz (5)En la tecnología de componentes la interfaz constituye el elemento básico de interconectividad. Cada componente debe describir de forma completa lasinterfaces que ofrece, así como las interfaces que requiere para su operación.La interfaz debe operar correctamente con independencia de los mecanismos internos que utilice para soportar su funcionalidad. Material Preparado por MARTA SILVIA Flujo de Diseño UP TABARES B. UdeM
  • 25. Modelos de Componentes (1)• Un componente puede tener atributos y operaciones y pueden participar en relaciones de asociación y generalización. Flujo de Diseño UP Material Preparado por MARTA SILVIA TABARES B. UdeM
  • 26. Modelos de Componentes (2) Material Preparado por MARTA SILVIA Flujo de Diseño UP TABARES B. UdeM
  • 27. Modelos de Componentes (3) cmp Modelo de Componentes Modelo de Componentes + Active X Control + Dll + JavaBean + W eb Pages + Web Server + Node Material Preparado por MARTA SILVIA Flujo de Diseño UP TABARES B. UdeM
  • 28. Paquetes vs Componentes Ejemplo (1): Modelo de Paquetespkg Sistema Univ ersitario AgendaCalendario + Curso + Localizacion + Matricula + Seminario Estereotipo <<application>> indica que + T iempo «import» el paquete tiene interfaces de usuario (UI) Estudiante Punto de Contacto Infraestructura Jav a «application» Registro Seminarios «import» Profesor «import» «import» Material Preparado por MARTA SILVIA TABARES B. UdeM Flujo de Diseño UP Fuente: http://www.agilemodeling.com/artifacts/componentDiagram.htm
  • 29. Paquetes vs ComponentesEjemplo(2): Modelo de ComponentesFuente: http://www.agilemodeling.com/artifacts/componentDiagram.htm Material Preparado por MARTA SILVIA TABARES B. UdeM Flujo de Diseño UP
  • 30. Cohesión y Acoplamiento• Cohesión: implica que un componente o clase encapsula solo atributos y operaciones que están altamente relacionados entre ellas y con la clase. Se busca la máxima cohesión en una clase.• Acoplamiento: es la medida cualitativa del grado en que una clase está conectada con otra. Se busca el mínimo acoplamiento entre clases. Material Preparado por MARTA SILVIA Flujo de Diseño UP TABARES B. UdeM
  • 31. Cohesión y Acoplamiento Material Preparado por MARTA SILVIA Flujo de Diseño UP TABARES B. UdeM
  • 32. Tipos de Cohesión Tomado de: http://www.eici.ucm.cl/Academicos/R_Villarroel/descargas/ing_sw_1/Criterios_Diseno_cohesion.pdf Material Preparado por MARTA SILVIA Flujo de Diseño UP TABARES B. UdeM
  • 33. Alta CohesiónIndica la información que almacena una clase debe de sercoherente y debe estar (en la medida de lo posible)relacionada con la clase.Cohesión Coincidente: El módulo realiza múltiples tareas, sin ninguna relaciónentre ellas.Cohesión Lógica: El módulo realiza múltiples tareas relacionadas, pero, entiempo de ejecución, sólo una de ellas será llevada a cabo.Cohesión Temporal: Las tareas llevadas a cabo por un módulo tienen, comoúnica relación el deber ser ejecutadas “al mismo tiempo”. Material Preparado por MARTA SILVIA Flujo de Diseño UP TABARES B. UdeM
  • 34. Alta CohesiónLa cohesión tiene que ver con la forma en la queagrupamos unidades de software en una unidadmayor.Por ejemplo, la forma en la que agrupamosfunciones en una librería, o la forma en la queagrupamos métodos en una clase, o la forma enla que agrupamos clases en una librería, etc... Material Preparado por MARTA SILVIA Flujo de Diseño UP TABARES B. UdeM
  • 35. Alta CohesiónCohesión de Procedimiento: La única relación que guardan las tareas de unmódulo es que corresponden a una secuencia de pasos propia del “producto”.Cohesión de Comunicación: Las tareas corresponden a una secuencia depasos propia del “producto” y todas afectan a los mismos datos.Cohesión de Información: Las tareas llevadas a cabo por un módulo tienen supropio punto de arranque, su codificación independiente y trabajan sobre losmismos datos. El ejemplo típico: OBJETOSCohesión Funcional: Cuando el módulo ejecuta una y sólo una tarea,teniendo un único objetivo a cumplir, se dice que tiene CohesividadFuncional. Material Preparado por MARTA SILVIA Flujo de Diseño UP TABARES B. UdeM
  • 36. Bajo acoplamiento La idea de tener las clases lo menos ligadas entre sí que se pueda. De tal forma que en caso de producirse una modificación en alguna de ellas, se tenga la mínimarepercusión posible en el resto de clases, potenciando la reutilización, y disminuyendo la dependencia entre las clases. Material Preparado por MARTA SILVIA Flujo de Diseño UP TABARES B. UdeM
  • 37. Bajo acoplamientoDos unidades están completamente desacopladas cuando hacensu trabajo de manera totalmente independiente. Esto nospermitiría coger una de ellas y utilizarla tal cual en un programasin necesidad de llevarnos la otra.• Por ejemplo, estos dos métodos (en C#), están totalmente desacoplados. Ninguno de ellos necesita al otro para hacer su trabajo. Material Preparado por MARTA SILVIA TABARES B. UdeM Flujo de Diseño UP
  • 38. Bajo acoplamiento• Acoplamiento normal: es aquel en el que una unidad de software necesita del trabajo que hace la otra. Así, descomponemos la solución de un problema en varias partes. Material Preparado por MARTA SILVIA Flujo de Diseño UP TABARES B. UdeM
  • 39. Acoplamiento normal• La comunicación entre las unidades debe de producirse utilizando puntos de entrada y de salida correctos y de su interfaz. Es decir, en el caso de los métodos. toda comunicación entre un método y otro acoplado normalmente debe producirse exclusivamente por los parámetros (como entrada) y por el retorno (como salida).• Si hablamos de métodos o funciones, los datos deben pasarse de una a otra a través de parámetros, y devolverse los resultados como retorno de la función o método y no de ninguna otra forma.• Una clase está acoplada a otra normalmente si los objetos de una utilizan a los de la otra, y se comunican invocando sus métodos y pasándoles datos como parámetros exclusivamente y recibiéndolos a través de canales normales, como retornos, propiedades, etc. Material Preparado por MARTA SILVIA Flujo de Diseño UP TABARES B. UdeM
  • 40. Otros tipos de AcoplamientoAcoplamiento de Datos: Una unidad de software está acoplada aotra por los datos cuando ambas necesitan del mismo conjuntolocal de datos para funcionar. Material Preparado por MARTA SILVIA Flujo de Diseño UP TABARES B. UdeM
  • 41. Otros tipos de AcoplamientoAcoplamiento de Control: Cuando un módulo le envía a otro un elemento de controlque determina la lógica de ejecución del mismo.Decimos que un método está acoplado a otro por control cuando de alguna maneraun método controla la ejecución del otro. En general, suele ocurrir cuando un métodopasa algún parámetro a otro, y en función de él se comporta de una u otra manera. Material Preparado por MARTA SILVIA TABARES B. UdeM Flujo de Diseño UP
  • 42. Diagramas de Máquinas de EstadoUna máquina de estados o flujo de estados describe el comportamiento del sistema. Muestra todos losestados que un objeto puede tomar en la transición entre sus diferentes estados.Por el ejemplo, en la figura se muestra el diagrama de estados para la clase Seminar. Un seminario puedetomar diferentes estados: ser Propuesto (Proposed), Agendado (Scheduled), estar Abierto para matrícula(Open for Enrollment), estar lleno (full) o tener las matrículas cerradas (Closed to Enrollment) Material Preparado por MARTA SILVIA TABARES B. UdeM Flujo de Diseño UP
  • 43. Diagrama de Despliegue Los Diagramas de Despliegue muestran ladisposición física de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos Material Preparado por MARTA SILVIA Flujo de Diseño UP TABARES B. UdeM
  • 44. Diagrama de DespliegueLos estereotipos permiten precisar la naturaleza del equipo: - Dispositivos - Procesadores - MemoriaLos nodos se interconectan mediante soportes bidireccionales (en principio) quepueden a su vez estereotiparse Material Preparado por MARTA SILVIA Flujo de Diseño UP TABARES B. UdeM