faculdade de computação - mÓdulobacala/daw/aula01-2- processos de...especificação de software...

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


WAI/

– Internacionalização


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;


• Eficiência:

– Tempo e Recursos;

• Manutenibilidade:

– Analisabilidade, Modificabilidade, Estabilidade e Testabilidade;

• Portabilidade:

– Adaptabilidade, Capacidade para ser instalado, Conformidade e Capacidade para substituir.

DAW4 57


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


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


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


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


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


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)


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

faculdade de computação - mÓdulobacala/daw/aula01-2- processos de...especificação de software...

Documents