MÓDULO Análise Orientada a Objeto Processos de Desenvolvimento de Software
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
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
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
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
Modelo cascata Resposta ao modelo code-and-fix vigente na década de 70 DAW4 6
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
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
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
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
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
Desenvolvimento incremental DAW4 12
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
Metodologias Ágeis DAW4 14
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
Modelo espiral do processo de software DAW4 16
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
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
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
O processo de engenharia de requisitos Também pode envolver a prototipação de partes do sistema! DAW4 20
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
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
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
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
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
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
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
ALGUNS MODELOS USADOS NA PRÁTICA DAW4 28
Evolução de software DAW4 29
Formato de Fábrica de Software DAW4 30
Agil com Sprints DAW4 31
Desenvolvendo com outsourcing DAW4 32
Metodologia com foco no cliente DAW4 33
(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
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
Iterativo e Incremental DAW4 36
Iterativo e Incremental DAW4 37
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
Modelo de fases do RUP Centrado no gerenciamento de projetos DAW4 39
Conceitos do RUP DAW4 40
Workflows estáticos DAW4 41
Resumindo o RUP DAW4 42
Resumindo o RUP DAW4 43
Resumindo o RUP DAW4 44
Resumindo o RUP DAW4 45
MÓDULO Sistemas Web
OBJETIVO DO MÓDULO Apresentar sistemas Web Características Propósitos Requisitos Não Funcionais de Sistemas Web DAW4 47
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
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
Sistemas Web - Propósitos Informativo: Prestar informações Funcional: Oferecer serviços Entretenimento: Divertir pessoas DAW4 50
Sistemas Web - Propósitos Fonte: Design e Usabilidade de Sistemas Web, Jair C. Leite (DIMAp UFRN) DAW4 51
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
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
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
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 http://www.w3.org/ 2001/sw/ Acessibilidade http://www.w3.org/ WAI/ Internacionalização http://www.w3.org/ International/ DAW4 55
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
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
Requisitos Não Funcionais Tecnologia Fonte: Design e Usabilidade de Sistemas Web, Jair C. Leite (DIMAp UFRN) DAW4 58
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
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
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
MÓDULO Análise Orientada a Objetos Engenharia Web
Roteiro Engenharia de Software e seu objetivo Modelo de Processo de Software para Web Exemplo DAW4 63
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
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
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
Modelo de processo Pressman [2001] DAW4 67
Modelo de processo Lowe & Eklund [2002] DAW4 68
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
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)
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
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
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
Diagrama de Classes
Arquitetura
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
Arquitetura
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.
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
Projeto de Interface Abstrata ADV: Detalhes do Hotel Nome (texto) Endereço (texto) Email (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)
Projeto de Interface Abstrata ADV: Detalhes do Hotel Nome (texto) Endereço (texto) Email (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 13000-000 Fone (19) 555-6666 Fax (19) 555-7777 Email: xyz@maximus.com.br Centro de convenções para 500 pessoas, american bar, Restaurante húngaro, pista de boliche, heliponto. foto Mais Fotos Apartamentos & Suítes
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
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
Referências R.S. Pressman, (2001) Software Engineering: A practitioner s approach, 5th ed. McGraw-Hill, ISBN 0-07-365578-3. 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). http://www.oohdm.inf.puc-rio.br:8668/space/start, ú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. 1995. 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, 52-58. 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