MÓDULO. Análise Orientada a Objeto Processos de Desenvolvimento de Software

Transcrição

1 MÓDULO Análise Orientada a Objeto Processos de Desenvolvimento de Software

2 OBJETIVO DO MÓDULO Revisitar os conceitos de processos de software Apresentar alguns modelos clássicos e alguns sendo utilizados na prática DAW4 2

3 Roteiro Processo de Software Modelos de Processos de Software Atividades Básicas de um Processo de Software Exemplos de Processos de Software RUP Rational Unified Process DAW4 3

4 O processo de software Um conjunto estruturado de atividades, procedimentos, artefatos e ferramentas necessários para o desenvolvimento de um sistema de software Atividades: Especificação, Projeto, Validação, Evolução Exemplos: Processo Unificado (RUP), Programação Extrema, UML Components Um modelo de processo de software apresenta a descrição de um processo de uma perspectiva particular, normalmente focando apenas em algumas atividades. DAW4 4

5 Modelos genéricos de processo de software O modelo cascata Fases separadas e distintas de especificação e desenvolvimento. Engenharia de software baseada em componentes O sistema é montado a partir de componentes existentes. Desenvolvimento iterativo Sistema desenvolvido através de várias etapas Existem muitas variantes destes modelos Ex: desenvolvimento formal onde um processo semelhante ao cascata é usado, mas a especificação formal é refinada durante os vários estágios para um projeto implementável. DAW4 5

6 Modelo cascata Resposta ao modelo code-and-fix vigente na década de 70 DAW4 6

7 Modelo cascata Fases Análise e definição de requisitos Projeto de sistema e software Implementação e teste de unidade Integração e teste de sistema Operação e manutenção Primeiro modelo a organizar as atividades de desenvolvimento Uma fase tem de estar completa antes de passar para a próxima. Saídas das fases são acordadas contratualmente! Todas as fases envolvem atividades de validação DAW4 7

8 Problemas do modelo cascata Particionamento inflexível do projeto em estágios Dificulta a resposta aos requisitos de mudança do cliente. Documentos completamente elaborados são necessários para fazer as transições entre estágios Apropriado somente quando os requisitos são bem compreendidos e quando as mudanças são raras Poucos sistemas de negócio têm requisitos estáveis. O modelo cascata é o mais usado em projetos de engenharia de sistemas de grande porte, onde um sistema é desenvolvido em várias localidades. DAW4 8

9 Engenharia de software baseada em componentes Baseado em reuso sistemático onde sistemas são integrados a partir de componentes existentes ou de sistemas COTS (Commercial-of-the-shelf) Estágios do processo Análise de componentes; Modificação de requisitos; Projeto de sistema com reuso; Desenvolvimento e integração. Esta abordagem está se tornando cada vez mais usada à medida que padrões de componentes têm surgido. Reuso acidental vs. Reuso planejado DAW4 9

10 Processos Iterativos Requisitos de sistema SEMPRE evoluem no curso de um projeto Algum retrabalho é necessário A abordagem iterativa pode ser aplicada a qualquer um dos modelos genéricos do processo. Duas abordagens (relacionadas) Entrega incremental; Desenvolvimento espiral. DAW4 10

11 Entrega incremental O sistema é entregue ao cliente em incrementos Cada incremento fornece parte da funcionalidade Os requisitos são priorizados Requisitos de prioridade mais alta são incluídos nos incrementos iniciais Uma vez que o desenvolvimento de um incremento é iniciado, os requisitos são congelados Os requisitos para os incrementos posteriores podem continuar evoluindo (e incluir requisitos já implementados!) DAW4 11

12 Desenvolvimento incremental DAW4 12

13 Vantangens do desenvolvimento incremental Incrementos podem ser entregues regularmente ao cliente e, desse modo, a funcionalidade de sistema é disponibilizada mais cedo. Os incrementos iniciais agem como protótipos para elicitar os requisitos para incrementos posteriores do sistema. Riscos menores de falha geral do projeto. Os serviços de sistema de mais alta prioridade tendem a receber mais testes. DAW4 13

14 Metodologias Ágeis DAW4 14

15 Desenvolvimento espiral O processo é representado como uma espiral ao invés de uma seqüência de atividades com realimentação. Cada loop na espiral representa uma fase no processo. Sem fases definidas, tais como especificação ou projeto os loops na espiral são escolhidos dependendo do que é requisitado. Os riscos são explicitamente avaliados e resolvidos ao longo do processo. DAW4 15

16 Modelo espiral do processo de software DAW4 16

17 Setores do modelo espiral Definição de objetivos Objetivos específicos para a fase são identificados. Avaliação e redução de riscos Riscos são avaliados e atividades são realizadas para reduzir os riscoschave. Desenvolvimento e validação Um modelo de desenvolvimento para o sistema, que pode ser qualquer um dos modelos genéricos, é escolhido. Planejamento O projeto é revisado e a próxima fase da espiral é planejada. Processo de Desenvolvimento vs. Processo de Gerenciamento DAW4 17

18 Atividades de um processo de desenvolvimento 1. Especificação de software 2. Projeto e implementação de software 3. Validação de software 4. Evolução de software DAW4 18

19 1 - Especificação de software O processo para definir quais serviços são necessários e identificar as restrições de operação e de desenvolvimento do sistema. Processo de engenharia de requisitos Estudo de viabilidade; Realizado antes do projeto ser iniciado Elicitação e análise de requisitos; Especificação de requisitos; Validação de requisitos. DAW4 19

20 O processo de engenharia de requisitos Também pode envolver a prototipação de partes do sistema! DAW4 20

21 2 - Projeto e implementação de software É o processo de conversão da especificação em um sistema de software Projeto de software Projetar uma estrutura de software que atenda à especificação. Implementação Transformar essa estrutura em um programa executável. As atividades de projeto e implementação são fortemente relacionadas e podem ser intercaladas. DAW4 21

22 Atividades do processo de projeto Projeto de arquitetura Especificação abstrata Projeto de interfaces entre componentes Projeto de componente Projeto de estrutura de dados Projeto de algoritmo DAW4 22

23 Métodos estruturados Abordagens sistemáticas para projetar sistemas de software Project (gerenciamento) vs. Design (desenvolvimento) O projeto é, em geral, documentado como um conjunto de modelos gráficos Modelos possíveis Modelo de objeto; Modelo de sequência; Modelo de transição de estado; Modelo estruturado; Modelo de fluxo de dados. DAW4 23

24 Programação e depuração É a transformação de um projeto em um programa e a remoção de defeitos desse programa. Programação é uma atividade pessoal não há processo genérico de programação. Há algumas práticas, porém, que são universalmente consideradas boas Programadores realizam alguns testes para descobrir defeitos no programa e removem esses defeitos no processo de depuração DAW4 24

25 3 - Validação de software Verificação e validação (V & V) têm a intenção de mostrar que um sistema está em conformidade com a sua especificação e que atende aos requisitos do cliente Verificação: construímos o sistema corretamente? Validação: construímos o sistema correto? Testes envolvem a execução do sistema com casos de teste que são derivados da especificação do sistema e de dados reais a ser processados por ele. DAW4 25

26 Estágios de teste Teste de componente ou unidade Os componentes individuais são testados independentemente; Esses componentes podem ser funções ou classes de objetos, ou grupos coerentes dessas entidades. Teste de sistema Teste de sistema como um todo. O teste das propriedades emergentes é particularmente importante. Teste de aceitação Teste com dados do cliente para verificar se o sistema atende às suas necessidades. DAW4 26

27 4 - Evolução de software O software é inerentemente flexível e pode mudar Requisitos mudam devido a diversos fatores e o software deve acompanhar essas mudanças Processos antigos separavam explicitamente desenvolvimento de evolução Processos e métodos iterativos (XP, RUP, Espiral) normalmente não fazem uma sepação explícita Evolução pode se dever a diversas razões: Correções (patches) Mudanças de requisitos Melhoria de funcionalidades pré-existentes DAW4 27

28 ALGUNS MODELOS USADOS NA PRÁTICA DAW4 28

29 Evolução de software DAW4 29

30 Formato de Fábrica de Software DAW4 30

31 Agil com Sprints DAW4 31

32 Desenvolvendo com outsourcing DAW4 32

33 Metodologia com foco no cliente DAW4 33

34 (Rational) Unified Process É um ( modelo de?) processo moderno baseado na UML Tenta cobrir todos os aspectos do desenvolvimento de software Fortemente focado na documentação do sistema Normalmente descrito a partir de três perspectivas: Uma perspectiva dinâmica que mostra as fases ao longo do tempo; Uma perspectiva estática que mostra atividades de processo; Uma perspectiva prática que sugere bons princípios e práticas de desenvolvimento DAW4 34

35 Boas práticas do RUP Desenvolver o software iterativamente Gerenciar requisitos Usar arquiteturas baseadas em componentes Modelar o software visualmente Verificar a qualidade de software Controlar as mudanças do software DAW4 35

36 Iterativo e Incremental DAW4 36

37 Iterativo e Incremental DAW4 37

38 Fases do RUP Concepção Estabelecer o business case para o sistema. Elaboração Desenvolver um entendimento do domínio do problema e a arquitetura do sistema. Construção Projeto, programação e teste de sistema. Transição Implantar o sistema no seu ambiente operacional. DAW4 38

39 Modelo de fases do RUP Centrado no gerenciamento de projetos DAW4 39

40 Conceitos do RUP DAW4 40

41 Workflows estáticos DAW4 41

42 Resumindo o RUP DAW4 42

43 Resumindo o RUP DAW4 43

44 Resumindo o RUP DAW4 44

45 Resumindo o RUP DAW4 45

46 MÓDULO Sistemas Web

47 OBJETIVO DO MÓDULO Apresentar sistemas Web Características Propósitos Requisitos Não Funcionais de Sistemas Web DAW4 47

48 Sistemas Web - Características Uso de infra-estrutura de terceiros. Servidores Web, BD Internet Cliente com Web Browser Aplicação Terceirizável Manutenção Mínima, Tempo Zero de Configuração

49 Sistemas Web - Características Alta Usabilidade Uso em larga escala de componentes de software Segundo Pressman, um sistema web: Está sempre em evolução É voltado para execução em rede Possui grande valor de conteúdo DAW4 49

50 Sistemas Web - Propósitos Informativo: Prestar informações Funcional: Oferecer serviços Entretenimento: Divertir pessoas DAW4 50

51 Sistemas Web - Propósitos Fonte: Design e Usabilidade de Sistemas Web, Jair C. Leite (DIMAp UFRN) DAW4 51

52 Sistemas Web Atributos da aplicação [Pressman 2001] Uso intensivo da rede Internet, intranet e extranet Diversos e diferentes grupos de usuários Evolução contínua... e rápida (horas?) Estrutura e funcionalidade Informação Direcionadas a conteúdo Hipermídia DAW4 52

53 Sistemas Web Atributos do processo [Pressman 2001] Características que direcionam o desenvolvimento Estética Sucesso da aplicação Urgência Adaptação dos métodos Segurança Aplicação e infraestrutura DAW4 53

54 Sistemas Web Atributos de qualidade [Pressman 2001] Usabilidade Funcionalidade Confiabilidade Eficiência Manutenibilidade Base para avaliar a qualidade de aplicações Web ISO/IEC 9126 Software product evaluation Quality characteristics and guidelines for their use Portabilidade Qualidade de Aplicações Web [Rocha et al. 2001] DAW4 54

55 Sistemas Web Tecnologias [Pressman 2001] Desenvolvimento baseado em componentes Construir menos e reusar mais Substituir um componente por outro Segurança Permitir apenas acesso autorizado Padrões W3C (sopa de letrinhas!) Web Semântica /sw/ Acessibilidade WAI/ Internacionalização International/ DAW4 55

56 Requisitos Não Funcionais Confiabilidade: Maturidade, Tolerância a Falhas e Recuperabilidade; Funcionalidade: Adequação, Acurácia, Interoperabilidade, Conformidade e Segurança de Acesso; Usabilidade: Inteligibilidade, Apreensibilidade e Operacionalidade; DAW4 56

57 Requisitos Não Funcionais Eficiência: Tempo e Recursos; Manutenibilidade: Analisabilidade, Modificabilidade, Estabilidade e Testabilidade; Portabilidade: Adaptabilidade, Capacidade para ser instalado, Conformidade e Capacidade para substituir. DAW4 57

58 Requisitos Não Funcionais Tecnologia Fonte: Design e Usabilidade de Sistemas Web, Jair C. Leite (DIMAp UFRN) DAW4 58

59 Sistemas e Aplicações Baseados na Web Inclui uma mistura entre imprensa e desenvolvimento de software, entre mercado e computação, entre comunicações internas e relações externas, e entre arte e tecnologia. Thomas Powell DAW4 59

60 Sistemas e Aplicações Baseados na Web Exemplos: Web sites completos; Funcionalidades especializadas dentro de Web sites; Aplicações de processamento de informação (em: Internet, Intranet ou Extranet); DAW4 60

61 Sistemas e Aplicações Baseados na Web Atributos comuns à maioria das WebApps: Baseadas em rede; Direcionadas a conteúdo; Evolução contínua. Influem na maneira como a Engenharia para Web é conduzida DAW4 61

62 MÓDULO Análise Orientada a Objetos Engenharia Web

63 Roteiro Engenharia de Software e seu objetivo Modelo de Processo de Software para Web Exemplo DAW4 63

64 Engenharia de Software Enfoque sistemático para o desenvolvimento, operação, manutenção e descontinuação do software (IEEE) Aplicação prática do conhecimento científico no projeto e construção de programas e da documentação requerida para desenvolver, operar e manter esses programas (Boehm) Disciplina que aplica os princípios de engenharia com o objetivo de produzir software de alta qualidade a baixo custo (Bauer) DAW4 64

65 Objetivo da Engenharia de Software Produzir software de alta qualidade a baixo custo Usando Modelos de Processo de Software Conjunto de atividades, métodos, técnicas e ferramentas que garantem que o software seja produzido com alta qualidade e baixo custo DAW4 65

66 Engenharia de Web A aplicação das práticas de engenharia no desenvolvimento de Aplicações Web Objetivo: produzir Aplicações Web de alta qualidade a baixo custo Abordagem ad hoc para desenvolvimento de Aplicações Web Os princípios, conceitos e métodos de engenharia podem ser aplicados ao desenvolvimento de Aplicações Web? Por que a Engenharia de Web é importante? DAW4 66

67 Modelo de processo Pressman [2001] DAW4 67

68 Modelo de processo Lowe & Eklund [2002] DAW4 68

69 Um Processo de Engenharia para Web Planejamento do Projeto Projeto Arquitetural Formulação do Problema Projeto Navegacional Análise de Requisitos Arquitetura da Informação + Projeto da Interação Projeto de Interface Implementação do Sistema Dica: considerar as restrições impostas pelas características das diferentes WebApps Revisão de modelos de análise e projeto Revisão especializada de usabilidade Testes (conteúdo, funcionalidade e compatibilidade) DAW4 69

70 Projeto Arquitetural Decomposição OO Requisitos funcionais: diagramas Orientada de classes, a Dados templates de classes Modelo E-R Visão Lógica Decomposição em Subsistemas Módulos, Subsistemas, Camadas Visão de Desenvolvimento Cenários Decomposição de Processo Requisitos não-funcionais: diagramas de componentes (UML) Visão de Processo Visão Física Mapeamento do Sw para o Hw Requisitos não-funcionais (Kruchten, 1995)

71 Estudo de Caso Sistema de Hotel Um grupo de empresários deseja que sua equipe desenvolva um sistema para gerenciar reservas e ocupações de apartamentos em uma rede de hotéis. O sistema será utilizado para controlar serviços internos de cada hotel e para a comunicação entre hotéis da rede de forma que seja possível que uma unidade da rede faça consultas sobre a disponibilidade de vagas em outras unidades da mesma cidade ou região. DAW4 71

72 Estudo de Caso Sistema de Hotel Serviços Básicos: Cadastro de clientes (hóspedes), apartamentos e despesas; Verificação de disponibilidade (via atendente por telefone ou via WEB); Controle de reserva (e cancelamento de reserva) de apartamentos; Controle de ocupação de apartamentos; Controle de pagamento (emissão da conta, emissão de fatura e registro do pagamento); Emissão de relatórios gerenciais (que devem ser sugeridos pelos desenvolvedores). DAW4 72

73 Estudo de Caso Sistema de Hotel Verificar Disponibilidade Descrição: Apresentar tipos de quarto disponíveis com seu valor para um determinado período. Atores: Usuário Web Prioridade: Essencial Pré-Condições: Cadastro de tipo de quarto. DAW4 73

74 Diagrama de Classes

75 Arquitetura

76 Arquitetura Subsistema: Disponibilidade Tipo de Componente: Buscador Função: buscar apartamentos disponíveis em um dado período em um dado Hotel. apresentar tipo de apto vago e seu valor

77 Arquitetura

78 Projeto Atividade Produtos Mecanismos Interesses Projeto da Navegação Nós, elos, estruturas de acesso, contextos de navegação, transformações navegacionais. Mapeamento entre objetos conceituais e de navegação. Padrões de navegação para a descrição da estrutura geral da aplicação. Leva em conta o perfil do usuário e a tarefa; ênfase em aspectos conceituais e arquiteturais. Projeto da Interface Abstrata Objetos de interface abstrata, reações a eventos externos, transformações de interface. Mapeamento entre objetos de navegação e objetos de interface. Modelagem de objetos perceptíveis, implementa metáforas escolhidas. Descrição de interface para objetos navegacionais.

79 Projeto Navegacional Início da Consulta Busca de Hotel por Cidade Lista de Estados Lista de Cidades Busca de Eventos Lista de eventos nos próximos 18 meses Detalhes do Evento Lista de Hotéis Busca por Quarto Tipos de Quarto Detalhes do Hotel Período de Estadia Lista de eventos neste hotel Quartos Disponíveis

80 Projeto de Interface Abstrata ADV: Detalhes do Hotel Nome (texto) Endereço (texto) (link) ADV: características do hotel Foto do Hotel (imagem) Galeria de fotos (link) Tipos de quartos (link) ADV: Início da Consulta Nome da rede de hotéis (texto) Busca de Hotel por Cidade (link: ADV: Hotel por Cidade) Busca de Eventos (link: ADV: Busca de Eventos) ADV: Hotel por Cidade Lista de estados (listbox, ação: preenche lista de cidades) Lista de cidades (listbox dinâmica, ação: preenche lista de hotéis) Lista de Hotéis (lista dinâmica de links)

81 Projeto de Interface Abstrata ADV: Detalhes do Hotel Nome (texto) Endereço (texto) (link) ADV: características do hotel Foto do Hotel (imagem) Galeria de fotos (link) Tipos de quartos (link) Hotel XYZ Plaza Residence Maximus Av. Comendador Shinezaki 999 Cambuí Campinas SP Fone (19) Fax (19) Centro de convenções para 500 pessoas, american bar, Restaurante húngaro, pista de boliche, heliponto. foto Mais Fotos Apartamentos & Suítes

82 Validação de Projeto. Conheça o modelo antes de validá-lo: Para um dado cenário, examine todas as medidas de performance das saídas do modelo e pergunte São razoáveis?. Utilize parâmetros de entrada para validar o modelo: Quando alguma entrada for alterada, examine as tendências em medidas de performance comuns. Usualmente o caminho é conhecido, a menos que a mudança seja muito importante DAW4 82

83 Validação de Projeto Projeto de um sistema novo: validação científica completa não é possível, não existe para comparação. essencial que os projetistas examinem e verifiquem a conduta dos modelos em cada nível. inclui como o modelo responde em situações extremas bem como em situações normais. DAW4 83

84 Referências R.S. Pressman, (2001) Software Engineering: A practitioner s approach, 5th ed. McGraw-Hill, ISBN B. Haire, B. Henderson-Sellers, D. Lowe (2001) Supporting web development in the OPEN process: additional tasks Submitted to COMPSAC'2001: International Computer Software and Applications Conference, Chicago, Illinois, USA. A.M.B.R. Carvalho, T.C.S. Chiossi, "Introdução à Engenharia de Software", Campinas, SP; Editora da Unicamp, (2001). G. Rossi An Object-Oriented Method for Designing Hypermedia Applications. PHD Thesis, Departamento de Informática, PUC-Rio, Brazil, July 1996 (in Portuguese). D. Schwabe, R.A. Pontes, I. Moura, "OOHDM-Web: An Environment for Implementation of Hypermedia Applications in the WWW", PUC-Rio, Brazil (1998). último acesso 09/11/2004. D. Schwabe, G. Rossi, The Object-Oriented Hypermedia Design Model, Comm. of the ACM, 38(8), pp 45-46, Aug D. Schwabe, G. Rossi, "Developing hypermedia applications using OOHDM. In Workshop on Hypermedia Development, Pittsburgh, USA, June 1998 J. S. Carson, Model Verification and Validation. In Proceedings of the 2002 Winter Simulation Conference, ed. E. Yücesan, C. H. Chen, J. L. Snowdon, and J. M. Charnes, Piscataway, New Jersey: Institute of Electricel and electronics Engineers. Victor F.A. Santander, Jaelson F. B. Castro, Márcio A. S. Bueno, Estudo de Princípios de Qualidade em Aplicações Web, Universidade Federal de Pernambuco Centro de Informática Jair C. Leite, Design e Usabolidade em Sistemas Web, DIMAp-UFRN (2002) Eliane Martins, Projeto Arquitetural, IC-UNICAMP (2001) DAW4 84