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 riscos-
chave.
• 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 Cliente com
Web Browser Internet
Terceirizável Manutenção Mínima,
Tempo Zero de Configuração
Aplicaçã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
DAW4 51
Fonte: Design e Usabilidade de Sistemas Web, Jair C. Leite (DIMAp – UFRN)
Sistemas Web
Atributos da aplicação
[Pressman 2001]
• Uso intensivo da rede
– Internet, intranet e extranet
– Diversos e diferentes
grupos de usuários
• Direcionadas a conteúdo
– Hipermídia
• Evolução contínua
– ... e rápida (horas?)
– Estrutura e funcionalidade
– Informação
DAW4 52
Sistemas Web
Atributos do processo
[Pressman 2001]
• Características que
direcionam o
desenvolvimento
• Urgência
– Adaptação dos métodos
• Segurança
– Aplicação e infraestrutura
• Estética
– Sucesso da aplicação
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
DAW4 56
• 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;
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
DAW4 65
• 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
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
Formulação do Problema
Planejamento do Projeto
Análise de Requisitos
Projeto Arquitetural
Projeto Navegacional
Projeto de Interface
Implementação do Sistema
Testes (conteúdo, funcionalidade e compatibilidade)
Revisão de modelos de
análise e projeto
Revisão especializada de usabilidade
Dica: considerar as restrições impostas pelas características
das diferentes WebApps
Arquitetura da Informação + Projeto da Interação
DAW4 69
Projeto Arquitetural
Visão Lógica Visão de
Desenvolvimento
Visão de Processo Visão Física
Cenários
(Kruchten, 1995)
Decomposição OO
Requisitos funcionais: diagramas de classes, templates de classes
Decomposição de Processo
Requisitos não-funcionais: diagramas de componentes (UML)
Orientada a Dados
Modelo E-R
Decomposição em Subsistemas
Módulos, Subsistemas, Camadas
Mapeamento do Sw para o Hw
Requisitos não-funcionais
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
Busca de Hotel por Cidade Busca de Eventos
Busca por Quarto
Detalhes do Evento
Início da Consulta
Lista de Estados
Lista de Cidades
Lista de Hotéis
Lista de eventos nos próximos 18 meses
Tipos de Quarto
Período de Estadia
Quartos Disponíveis
Detalhes do Hotel
Lista de eventos neste hotel
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
foto
Email: [email protected]
Centro de convenções para 500 pessoas, american bar, Restaurante húngaro, pista de boliche, heliponto.
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
Top Related