Analisis y Diseño de Sistemas II-1

Presentación realizada por el Prof. Daniel Gutiérrez Albenda de la Universidad Latina de Costa Rica

1. Análisis y Diseño de Sistemas II Prof. Daniel Gutiérrez Albenda

2. Evaluación Rubro Valor Prueba1 25% Prueba2 25% Prácticas, Foros, Quices , Tareas 10% Investigación 1 % Proyecto 30% Total 100%

3. Programación Orientada a Objetos(P.O.O.) ¿Qué es? La orientación a objetos es un concepto que abarca cualquier tipo de desarrollo basado en la idea de objeto (entidad que posee características y comportamiento). Estructura un programa dividiéndolo en una cantidad determinada de objetos de alto nivel. Los objetos interactúan entre sí para dar lugar al flujo total del programa. Atributos Nombre Edad Peso Comportamientos Comer Beber Dormir

4. Componentes de P.O.O. El dominio: Es el espacio donde se desarrolla un problema, es el conjunto de conceptos que representan los aspectos importantes del problema que intenta resolver (delimitación). Objeto: Es un componente de software que encapsula estado y un comportamiento. Los objetos permiten dar forma al software en términos y abstracciones reales. La POO agrupa los objetos de acuerdo con sus comportamientos y atributos comunes.

5. Componentes de P.O.O. Clase : Son las que agrupan los objetos que tienen alguna relación. La clase define los atributos y comportamientos exhibidos por el objeto. Definen de manera específica cuales mensajes responden a sus objetos, define la manera en la que los objetos responden a los mensajes. Cuando un objeto desea poner en práctica el comportamiento de otro objeto no lo hace directamente, sino que pide al otro objeto que se modifique a si mismo por lo general con base en alguna información adicional en el envío de mensajes. Las clases se usan para crear o distanciar objetos.

6. Componentes de P.O.O. Atributos : Son las características externas y visibles de una clase. Comportamiento: Es la acción que realiza un objeto cuando pasa un mensaje o en respuesta a un cambio de estado. Estado: Es algo que realiza un objeto. La propiedad concreta de un objeto es su estado (puede ser permanente o temporal).

7. Objetos Los objetos pueden relacionarse de dos formas distintas: Pueden existir de manera independiente uno de otro. Sin embargo si los objetos necesitan interactuar, lo pueden hacer intercambiando mensajes: los mensajes es el medio por el cual los objetos se comunican entre sí. Los mensajes dan como resultado que un objeto realice algo. La “acción” de pasar un mensaje es equivalente a llamar un método para modificar el estado del objeto para ejercer un comportamiento. Un objeto podría contener otros objetos. Los objetos pueden confirmar otros objetos a través de la agregación (métodos, datos variables ). Fruta

8. Objetos Nota : Los componentes de un objeto son objetos. Los mensajes permiten que los objetos conserven su independencia. Los dos conceptos primordiales de la POO son clase y objeto. Entonces un Objeto es cualquier cosa tangible e intangible que se pueda imaginar. Un programa de OO consistirá en una serie de objetos que interactúan entre sí. Fruta

9. Constructores Los constructores son métodos que se usan para inicializar objetos en la etapa de instanciación. La creación de objetos se denomina instanciación ya que durante esta se genera una instancia de un objeto de la clase. Los comportamientos de una clase son las “funciones” que se declaran dentro de una clase.

10. Identificación de Problemas, Oportunidades y Objetivos Por lo general existe un problema a resolver y hay una solicitud de un interesado. El analista debe observar objetivamente lo que sucede para identificar el problema real y determinar la factibilidad de solución. Se debe estar claro en cuales son los objetivos que se tienen al resolver el problema. Se conoce también como Estudio de Factibilidad. Se debe involucrar a los usuarios principales para identificar el alcance del proyecto.

11. Análisis y Diseño Tiene el propósito de estudiar el flujo de datos, el proceso y transformación de los mismos, el almacenamiento y el producto que se espera en el contexto de la organización. Se busca soluciones que mejoren el funcionamiento en las empresas. En la mayoría de los casos se busca una solución computarizada.

12. Requerimiento Acorde a la IEEE un requerimiento se define como: “…es la condición o capacidad que debe poseer un sistema o un componente de un sistema para satisfacer un contrato, un estándar, una especificación u otro documento formalmente impuesto…"

13. Determinación de Requerimientos Analizar detenidamente todos los componentes del sistema para entender la actividad y determinar el origen de los problemas. Se establecen alternativas de solución. Se determina: El quién. El qué. El dónde. El cuándo. El cómo

14. Requerimiento Funcionales El estándar IEEE-830 define: Los requerimientos funcionales describen una interacción entre el sistema y su ambiente, describen cómo debe comportarse el sistema ante determinado estímulo. Son declaraciones de los servicios que debe proporcionar el sistema, de la manera en que éste debe reaccionar a entradas particulares y de cómo se debe comportar en situaciones particulares. En algunos casos , también pueden declarar explícitamente lo que el sistema no debe hacer. Los requerimientos funcionales de un sistema describen lo que el sistema debe hacer .

15. Requerimiento No Funcionales El estándar IEEE-830 define: Los requerimientos no funcionales describen una restricción sobre el sistema que limita nuestras elecciones en la construcción de una solución al problema. Restringen los servicios o funciones ofrecidas por el sistema. Incluyen restricciones de tiempo, el tipo de proceso de desarrollo a utilizar, fiabilidad, tiempo de respuesta, capacidad de almacenamiento. Los requerimientos no funcionales ponen límites y restricciones al sistema.

16. Requerimientos no funcionales Requisitos del producto: Especifican el comportamiento del producto obtenido. Requisitos organizacionales: Son una consecuencia de las políticas y procedimientos existentes en la organización. Requisitos externos: Presentan factores externos al sistema y a su proceso de desarrollo.

17. Requerimientos no funcionales

18. Proceso de Ingeniería de Requerimientos

19. Proceso de Ingeniería de Requerimientos Estudio de Factibilidad: R ecomienda si es conveniente o no realizar recolección, organización y documentación los requerimientos del sistema (Ingeniería de Requerimientos) y el desarrollo del sistema propuesto. Obtención y Análisis de Requerimientos: Esta etapa comprende: Comprensión del dominio, Recolección de requerimientos, Clasificación de requerimientos, Resolución de conflictos, Priorización y Verificación de requerimientos. Especificación de Requerimientos: Define las actividades de: Contener todos los requerimientos deseados, Cada requerimiento solo tiene una interpretación posible, El cumplimiento de cualquier requerimiento no provoque conflictos con el cumplimiento de otro requerimiento, Prioridades definidas, entre otros. Validación de Requerimientos.

20. Especificación de Requerimientos La Especificación es un documento que define, de forma completa, precisa y verificable, los requisitos, el diseño y el comportamiento u otras características, de un sistema o componente de un sistema . Sommerville , 2005 plantea que una buena especificación debe procurar: Separar funcionalidad de implementación . Una especificación es una descripción de lo que se desea, en vez de cómo se realiza. Esto en la práctica puede llegar a no suceder del todo, sin embargo es un buen lineamiento a seguir .

21. Especificación de Requerimientos Una especificación debe abarcar el entorno en el que el sistema opera. Similarmente , el entorno en el que opera el sistema y con el que interactúa debe ser especificado. Debe ser modificable. Ninguna especificación puede ser siempre totalmente completa . El entorno en el que existe es demasiado complejo para ello. Una especificación es un modelo, una abstracción, de alguna situación real ( o imaginada ). Por tanto, será incompleta. Además, al ser formulada existirán muchos niveles de detalle.

22. Validación de Requerimientos Consiste en verificar que los requisitos levantados sean lo que el cliente necesita o desea. Verificaciones de validez: ¿Es realmente requerido? Verificaciones de consistencia: Los requerimientos en el documento no deben contradecirse. Verificaciones de completitud: Las funciones y restricciones propuestas por el usuario del sistema deben cumplirse. Verificación del realismo: Utilizando el conocimiento de la tecnología existente, los requerimientos deben verificarse para asegurar que se pueden implementar. Estas verificaciones también deben tener en cuenta el presupuesto y la confección de agendas para el desarrollo del sistema.

23. ¿Qué es UML?

24. Diagrama de Casos de Uso Actor Caso de uso Límite de un sistema << include >> Que un caso de uso se incluye dentro de la secuencia de otro. << extend >> Un caso de uso corresponde a un especiación de otro (Depositar Item se especia en Depositar Plástico, Depositar Aluminio y Depositar Vidrio). Asociation Conecta a los actores con los casos de uso. Relaciones

25. Escenario Lugar donde se desarrolla una acción o situación. Un escenario se constituye en un módulo del sistema. Ejemplos: Expediente de personal Planillas Capacitación Incapacidades

26. Actores Quienes interviene en el escenario. Ejemplos: Expediente de personal Recepcionista Analista de ofertas Jefe de personal

27. Identificar Métodos o Comportamientos o Procesos Es la acción que realiza un objeto(actor, sistema) cuando pasa un mensaje o en respuesta a un cambio de estado . Ejemplos: Escenario: Planillas Procesos: Registro de asistencia Aplicación de movimientos de personal Generación de planilla Emisión de cheques Emisión de comprobantes de pago Reporte de planillas Generación de Aguinaldos

28. Gracias Prof. Daniel Gutiérrez Albenda