Análise e Projeto Orientados a ObjetoNEW

Prévia do material em texto

Análise e Projeto Orientados a Objeto
Objetivos
· Comparar e contrastar Análise e Projeto
· Definir Análise e Projeto Orientados a Objeto
O que vamos fazer na disciplina?
· Saber uma linguagem de programação orientada a objeto (OO) não é suficiente para criar sistemas OO
· Tem que saber Análise e Projeto OO (APOO)
· Isto é, Análise e Projeto usando uma perspectiva de objetos
· Usaremos um estudo de caso para concretizar a discussão
· Usaremos a linguagem UML (Unified Modeling Language) para criar modelos (de análise e de projeto)
· Um modelo é uma representação abstrata dos aspectos essenciais de um sistema
· O que é "essencial" depende do momento da modelagem
· A UML usa uma representação principalmente gráfica para representar os modelos
· UML é muito popular hoje em dia para modelar sistemas
· Usaremos Design Patterns (padrões de projeto) para mostrar soluções abstratas para problemas que surgem frequentemente durante o projeto de sistemas OO
· Os patterns tratarão principalmente de:
· Como atribuir responsabilidades a objetos (uma das atividades mais difícil no desenvolvimento de sistemas OO)
· Como separar o que muda do que é constante numa determinada situação, com o objetivo de ganhar flexibilidade
· Para evitar "o efeito gelatina"
· Explicaremos e seguiremos um processo de desenvolvimento que mostra claramente quais são as etapas a seguir para produzir software de qualidade
· Veremos também quais artefatos devem ser produzidos na várias fases e etapas do processo
O que é Análise e Projeto?
· Diferenças entre análise e projeto: tem mais do que uma definição empregada 
· Primeira alternativa: 
· A análise modela o problema e consiste das atividades necessárias para entender o domínio do problema (o que deve ser feito). É uma atividade de investigação. 
· O projeto modela a solução e consiste das atividades de criação (como pode ser feito) 
· Segunda alternativa:
· A análise consiste de todas as atividades feitas com ou para o conhecimento do cliente. A informação produzida é aquela que o cliente deve discutir e aprovar
· O projeto inclui as atividades que resultam em informação que interessa apenas ao programador
· Com essa definição, a análise invade um pouco o "lado da solução", pois o cliente deve discutir alguns tipos de interações que ocorrerão na interface do usuário, etc.
· Observe portanto que não definição binária que isole "análise" de "projeto"
· Nesta disciplina, adotaremos a segunda alternativa, pois queremos associar as palavras "análise" e "projeto" aos artefatos (deliverables) entregues nos final de cada fase
· Um modelo de análise deve ser aprovado pelo cliente e pode incluir alguma (pequena) discussão da solução, principalmente no que diz respeito à interface com usuário, etc.
· Apesar do nome da disciplina, vamos ver também as fases de requisitos, implementação e testes
· A obtenção de requisitos é frequentemente incluída na fase de análise ("análise de requisitos")
O que é Análise e Projeto Orientados a Objeto (APOO)?
· A perspectiva empregada é de objetos (coisas, conceitos ou entidades)
· Durante a Análise OO, a ênfase está em achar e descrever objetos (ou conceitos) no domínio do problema
· Por exemplo, num sistema de informação para uma biblioteca, alguns dos conceitos são Livro, Biblioteca, Usuário.
· Tais objetos podem ter atributos e responsabilidades
· Durante o projeto orientado a objeto, a ênfase está em achar objetos lógicos de software que poderão ser eventualmente implementados usando uma linguagem de programação OO
· Tais objetos pode ter atributos e métodos
· Durante a construção (programação OO), os objetos do projeto são implementados e testados
APOO versus AP Orientados a Funções (APOF)
· Com ambas as técnicas, usa-se decomposição (chamado modularização em APOF) para lidar com a complexidade
· A APOF (também chamados de Análise e Projeto Estruturados), a decomposição é por função ou processo
Por que queremos Orientação a Objeto? Quais são as vantagens?
· As abstrações podem corresponder às coisas do domínio do problema
· O nível é mais natural
· É mais fácil comunicar-se com o usuário ou domain expert na linguagem dele
· Os mesmos objetos existem em todas as fases e uma notação única (objetos) facilita portanto a integração entre fases de desenvolvimento (passar de uma fase para a outra)
· Fases posteriores adicionam novos objetos mas os objetos do domínio do problema permanecem: são estáveis
· Isso ajuda o rastreamento de decisões de projeto e implementação
· É mais fácil entender o domínio do problema quando esta é quebrado em pedaços: gerenciamento da complexidade através da modularização
· O mesmo pode ser dito no domínio do computador (projetando e programando com objetos)
· A abstração controla a complexidade (escondendo algo através da separação da interface e da implementação)
· A encapsulação facilita as mudanças (através do isolamento)
· A hierarquia (grafo de herança) permite uma melhor reutilização
· Hierarquia promove a flexibilidade de fazer mudanças de forma localizada
· Exemplo: novos trechos de programas podem usar uma sub-classe nova e código antigo continua usando a superclasse e não toma conhecimento das mudanças
· Porém, há problemas de acoplamento com herança que veremos em outro capítulo
· A reutilização de pedaços é mais difícil usando paradigmas anteriores (modularização via funções) porque não posso usar coisas pré-existentes tão facilmente
· Com objetos, posso dizer: "me dê dois daqueles" porque objetos têm estado
· Não posso fazer isso com funções porque elas não encapsulam estado
intro-1 programa próxima
O Processo de Desenvolvimento de Software
Objetivos
· Explicar a ordem dos capítulos subsequentes, que seguem as etapas de um processo de desenvolvimento de software
· Seguir um proceso de desenvolvimento de software desde a obtenção de requisitos até a implantação
Um processo de desenvolvimento de software
· Uma linguagem de modelagem não é suficiente
· Precisamos também de um processo de desenvolvimento
· Linguagem de modelagem + processo de desenvolvimento = método (ou metodologia) de desenvolvimento
· O que é um processo de desenvolvimento?
· Define quem faz o que, quando e como, para atingir um certo alvo 
· Veremos os detalhes de um processo ao longo da disciplina
· Por enquanto, só uma introdução 
· As grandes fases de qualquer processo de desenvolvimento
· Planejamento e elaboração
· Planejamento, definição de requisitos, construção de protótipos (opcional)
· Construção do sistema (inclui codificação e testes)
· Implantação (colocar em produção, treinar usuários,)
A Fase de Planejamento e Elaboração
1. Criar relatório inicial de investigação (para construir o business case)
2. Levantar requisitos funcionais e não funcionais
3. Construir glossário (ao longo da fase)
4. Definir modelo conceitual inicial (análise inicial)
5. Projetar arquitetura
6. Priorizar a funcionalidade e distribuí-la entre as iterações
Detalhes sobre o levantamento de requisitos
· Requisitos são "cortes" no espaço de solução
· Entendimento do que o usuário quer
· O resultado é uma promessa para o cliente
· Não só requisitos funcionais, mas também:
· Facilidade de uso necessária 
· Quem utilizará o produto 
· Hardware e software alvo para o produto 
· Qualidade/robustez
· Desempenho 
· Segurança 
· Compatibilidade com outros produtos/versões e necessidades de migração 
· Necessidades de internacionalização do produto 
· Suporte 
· Preço da solução 
· Documentação necessária 
· Uso de padrões 
· Aspectos legais 
· Integração com outros produtos 
· Packaging 
· etc. 
· Não se fala "como" as coisas serão feitas
· "use cases" descrevem cenários de funcionalidade desejada 
Detalhes sobre a fase de Construção
· Hoje, é considerado errado ter um processo que gere um "big bang!"
· Não se deve ter o software inteiro funcionando por inteiro no primeiro release
· O risco é grande demais!
· Um processo de desenvolvimento deve ser:
· Iterativo (ter várias iterações no tempo)
· Incremental (gerar novas versões incrementadas a cada release) 
· Uma iteraçãodura entre 2 semanas e 2 meses
· Motivos:
· Sempre tem algo poara entregar para o cliente apressado (a última iteração)
· Os requisitos mudam com tempo e um processo iterativo mantém frequentes contatos com o cliente o que ajuda a manter os requisitos sincronizados
· Altamente motivador para a equipe de desenvolvimento (e o cliente) ver o software funcionando cedo
· O que é feito a cada iteração?
· Análise (refinamento de requisitos, refinamento do modelo conceitual)
· Projeto (refinamento do projeto arquitetural, projeto de baixo nível)
· Implementação (codificação e testes)
· Transição para produto (documentação, instalação, ...)
Detalhes sobre a análise 
· A análise gera um modelo para entender o domínio do problema 
· Análise também trata em alto nível de como uma solução possível pode ser montada para atender aos requisitos 
· Acaba gerando uma especificação, mas sempre do ponto de vista do usuário e tratando apenas do domínio do problema 
· Não trata de detalhes de implementação 
· Objetos tratados são sempre do domínio do problema (business objects) 
· Muitos diagramas uml podem ser usados
· O modelo é para o cliente e não para o programador
· Atividades típicas durante a análise
1. Refinar use cases
2. Refinar modelo conceitual
3. Refinar glossário
4. Definir diagramas de sequência (opcional)
5. Definir contratos de operação (opcional)
6. Definir diagramas de estado (opcional)
Detalhes sobre o projeto (design)
· O projeto é uma extensão do modelo de análise visando sua implementação num computador 
· Novos objetos aparecem, mas não são do domínio do problema 
· O resultado é para o programador ver, não o cliente 
· Objetos da análise são (geralmente) mantidos e são embutidos numa infraestrutura técnica 
· As classes técnicas ajudam os business objects a: 
· Serem persistentes 
· Se comunicarem 
· Se apresentarem na interface do usuário 
· Terem desempenho aceitável (usando caches ou threads, por exemplo) 
· As atividades de projeto incluem: 
· Fase de refinamento da arquitetura (high level design) 
· Definição de pacotes (módulos), interfaces entre pacotes
· Decisão sobre uso/criação de bibliotecas e/ou componentes 
· Fase de low-level design
· Atribuição de responsabilidades entre os objetos
· Construção de diagramas de classes
· Pode incluir documentação javadoc (ideal)
· Construção de diagramas de interação (opcional)
· Levantamento de necessidades de concorrência 
· Considerações de tratamento de faltas
· Detalhamento do formato de saída (interface com usuário, relatórios, transações enviadas para outros sistemas, ...) 
· Definição do esquema do BD
· Mapeamento de objetos para tabelas se o BD for relacional
Detalhes sobre a implementação 
· Escrita do código 
· Relativamente simples se o projeto tiver sido bem feito 
· Programadores devem normalmente seguir regras de codificação da empresa 
· Atividades incluem code reviews 
· Não se deve chegar a esta fase cedo demais! 
· Mais cedo você agarra o teclado, mais vai demorar a terminar! 
· Poucos novos diagramas nesta fase 
Detalhes sobre os testes 
· Inclui várias fases de testes 
· Testes feitos pelo próprio programador 
· Unit test: teste de classes individuais (ou de grupos de classes relacionadas) 
· Function test: teste de funções inteiras (item de menu, p. ex.) 
· Component test: teste de componentes inteiros (exe, dll, ...) sem (ou com pouco) scaffolding 
· Testes feitos por equipes independentes de teste 
· System test: testa a integração entre todos os componentes do produto 
· Alpha test: teste de produto inteiro dentro de casa 
· Beta test: teste de produto inteiro fora de casa 
· Testes devem ser automatizados 
intro-2 programa anterior próxima
Modelos e Artefatos
Objetivos
· Definir os modelos e artefatos a serem produzidos durante o proceso de desenvolvimento de software
Os modelos e outros artefatos (deliverables)
· Artefatos da fase de elaboração
· Documento de business case (investigação preliminar)
· Documento de orçamento e cronograma
· Documento de especificação de requisitos
· Requisitos funcionais (Modelo de use case)
· Requisitos não funcionais
· Modelo conceitual inicial
· Glossário
· Projeto arquitetural (poderá incluir un Modelo de componentes)
· Fase de construção
· Refinamento dos requisitos funcionais (Modelo de use case)
· Refinamento do modelo conceitual (Modelo conceitual)
· Inclui vários tipos de diagramas UML
· Refinamento do projeto arquitetural (poderá incluir un Modelo de componentes)
· Refinamento do glossário
· Projeto de baixo nível (Modelo de projeto)
· Inclui vários tipos de diagramas UML
· Esquema de banco de dados
· Planos de testes
· Fase de implantação
· Planos de publicação
· Planos de testes alfa, beta
· Planos de treinamento
intro-3 programa anterior
Estudo de caso: Terminal Ponto de Venda (PDV)
Objetivos
· Introduzir o estudo de caso utilizado na disciplina
O Terminal de Ponto de Venda (PDV)
· Nosso estudo de caso envolve um Terminal PDV
· Um sistema computadorizado que registra vendas e trata de pagamentos
· Tipicamente usado numa loja de varejo
· Tipicamente está acoplado a um leitor de código de barra
· Trataremos do desenvolvimento do software que controla o terminal usando um processo de desenvolvimento iterativo-incremental
· Falaremos de requisitos, análise, projeto e implementação
· Este sistema envolve um sistema de informação típico e nos fará cruzar com muitas situações típicas
Arquitetura em camadas e ênfase do estudo
· Um sistema de informação típico é organizado usando as camadas apresentadas abaixo
· As camadas arquiteturais apresentadas são:
· Apresentação
· Interface gráfica, janelas
· Lógica de aplicação - Objetos do domínio de problema
· Objetos representando conceitos do domínio (business objects)
· Contém o que se chama também business logic
· Lógica de aplicação - Objetos de serviço
· Objetos que não pertencem ao domínio do problema mas oferecem serviços tais como interfaceamento para um banco de dados, etc.
· Armazenamento
· Mecanismos de armazenamento persistente (SGBDOO, SGBDR, SGBDOR)
· Usam-se Análise e Projeto OO principalmente nas camadas de lógica de aplicação
· Falaremos em mais detalhes sobre arquiteturas em camadas na seção 4.2 (Projeto arquitetural)
· Boa parte da disciplina tratará do business logic
· A seção 4.9 tratará de objetos para serviços de persistência
plan-1 programa próxima
Entendendo Requisitos
Objetivos
· Descrever os artefatos do processo de desenvolvimento relacionados aos requisitos
· Identificar e categorizar requisitos funcionais do sistema
· Identificar e categorizar requisitos não-funcionais do sistema (atributos do sistema)
Requisitos
· Requisitos são uma descrição de necessidades ou desejos para um produto.
· Motivo da fase de levantamento de requisitos: saber que sistema deve ser construido
· Se houver sucesso no levantamento de requisitos, não haverá surpresas desagradáveis para o usuário na entrega do sistema
· Artefatos típicos a serem criados
· Breve descrição do sistema
· Descrição dos clientes alvo
· Pode incluir como eles operam hoje e quais problemas eles enfrentam
· Descrição das metas do sistema
· Descrição dos requisitos funcionais do sistema
· Descrição dos requisitos não funcionais do sistema
· Usaremos o estudo de caso (Terminal PDV) para exemplificar a obtenção de requisitos
Breve descrição do sistema
· O objetivo do projeto é de criar um sistema para um Terminal Ponto de Venda (TPDV) a ser usado no comércio varejista.
Descrição dos clientes alvo
· O cliente é Xpto, Ltda., que vende TPDVs a lojas varejistas.
Descrição das metas do sistema
· A meta básica é de melhorar a automação do balcão de vendas, incluindo:
· Checkout mais rápido para o cliente
· Análise rápida e precisa das vendas
· Automatizar o controle de estoque
· Observe que, no Brasil, haveria outras considerações de ordem legal, incluindo o recolhimento de impostos
Descrição dos requisitos funcionais do sistema
· Requisitos funcionais descrevem o que o sistema deve fazer
· As categorias de requisitos funcionais são:
	Categoria de funcionalidade
	SignificadoEvidente
	Usuário está ciente de que a função está sendo feita
	Escondida
	Embora a função seja feita, ela é invisível ao usuário. Tal funcionalidade frequentemente é esquecida ao levantar requisitos
	Friso
	Funcionalidade opcional; sua adição não afeta outras funções ou o custo significativamente
· Funcionalidade básica
· A lista abaixo não é exaustiva mas servirá de exemplo para explicar as atividades do processo de desenvolvimento
· Observe que o levantamento dos requisitos funcionais deve ser completado usando use cases (discutidos no próximo capítulo)
· Use cases descrevem os processos do domínio do problema
· A lista abaixo pode servir para nortear o levantamento de use cases
· Alguns desenvolvedores usam apenas use cases para levantar os requisitos funcionais
· De toda forma, a tabela abaixo exemplifica o que se entende por requisito funcional
	Referência
	Funcionalidade
	Categoria
	R1.1
	Registrar a vanda corrente (os itens comprados)
	Evidente
	R1.2
	Calcular o total de venda, incluindo impostos e descontos aplicáveis
	Evidente
	R1.3
	Capturar a informação do item sendo comprado através de um leitor de código de barra, ou manualmente usando um código de produto tal como o Universal Product Code (UPC)
	Evidente
	R1.4
	Dar baixa no inventário ao terminar uma venda
	Escondida
	R1.5
	Manter um log de vendas feitas
	Escondida
	R1.6
	O caixa deve fazer login com uma identificação e uma senha antes de usar o sistema
	Evidente
	R1.7
	Deve prover um mecanismo persistente de armazenamento
	Escondida
	R1.8
	Prover integração com outros sistemas
	Escondida
	R1.9
	Exibir a descrição e o preço do item sob consideração
	Evidente
· Funcionalidade associada ao pagamento
	Referência
	Funcionalidade
	Categoria
	R2.1
	Tratar de pagamentos à vista com dinheiro, capturando o valor entregue e calculando o troco
	Evidente
	R2.2
	Tratar de pagamentos por cartão de crédito, capturando a informação do cartão através de um leitor de cartões ou por digitação manual e autorizando o pagamento usando o serviço de autorização de crédito da loja (um sistema externo) usando uma conexão via modem
	Evidente
	R2.3
	Tratar de pagamentos por cheque, capturando a informação de identidade/CPF por digitação manual e autorizando o pagamento usando o serviço de verificação de cheques da loja (um sistema externo) usando uma conexão via modem
	Evidente
	R2.4
	Lançar  os pagamentos via cartão de crédito no sistema de contas a receber, já que o serviço de cartão de crédito deve dinheiro à loja
	Escondida
Descrição dos requisitos não funcionais do sistema
· Requisitos não funcionais incluem requisitos das seguintes categorias
· Facilidade de uso necessária
· Tipo de interface desejada
· Quem utilizará o produto 
· Volume de utilização (número de usuários, número de transações, ...)
· Hardware e software alvo para o produto 
· Qualidade/robustez
· Tolerância a falha
· Desempenho 
· Segurança 
· Compatibilidade com outros produtos/versões e necessidades de migração 
· Necessidades de internacionalização do produto 
· Necessidades de customização do produto pelo cliente
· Suporte 
· Preço da solução 
· Documentação necessária 
· Uso de padrões 
· Aspectos legais 
· Integração com outros produtos 
· Packaging
· Requisitos de instalação
· Riscos aceitáveis
· Os requisitos não funcionais também são chamados de atributos do sistema
· Alguns exemplos seguem
	Atributo
	Detalhes ou condição limite
	Tempo de resposta
	(Condição limite) Ao registrar um item sendo vendido, a descrição e preço devem aparecer em 2 segundos
	Tipo de interface
	(Detalhe) Usar formulários para entrada de dados e dialog boxes
(Detalhe) Maximizar a facilidade de uso via teclado e não via mouse
	Tolerância a falhas
	(Condição limite) Deve fazer log dos pagamentos autorizados via cartão de crédito em 24 horas, mesmo com falhas de energia ou de dispositivo
	Plataformas operacionais
	(Detalhe) Microsoft Windows 95, Windows, 98, Windows NT e Windows 2000
plan-2 programa anterior próxima
Use Cases: Descrição de Processos
Objetivos
· Identificar e escrever use cases
· Diagramar use cases
· Constrastar use cases de alto nível e expandidos
· Contrastar use cases essenciais e reais
Introdução
· Use cases são usados para descrever os processos do domínio de problema
· São uma excelente forma de explorar e documentar os requisitos funcionais
· Antes de elaborar use cases, pode valer a pena elaborar uma tabela de funções básicas como vimos na seção anterior
Use cases
· Um use case é um documento narrativo que descreve uma sequência de eventos feitos por um ator no uso de um sistema para completar um processo de interesse deste ator.
· Use cases são "estórias" ou "casos" no uso de um sistema
· As estórias acabam revelando as funcionalidade desejada do sistema
· Em UML, um use case é representado assim:
Exemplo de um Use Case de alto nível: Comprar item
· Segue uma breve descrição do processo de comprar um item numa loja quando um TPDV é utilizado
Use case:	Comprar item
Atores:		Cliente, Caixa
Tipo:		primário (a ser explicado logo)
Descrição:	Um cliente chega ao caixa com itens a comprar.
		O caixa registra os itens comprados e recebe pagamento.
		No fim, o cliente sai com os itens comprados.
· UML não força o formato exato de um Use Case. A clareza na descrição é o essencial.
· Iniciamos acima com um Use Case de alto nível, fornecendo poucos detalhes
· Útil para entender rapidamente os processos principais envolvidos
Exemplo de um Use Case expandido: Comprar item com dinheiro vivo
· Ignoramos a questão de dar baixa no inventário aqui
Use case:	Comprar item com dinheiro
Atores:		Cliente (iniciador), Caixa
Propósito:	Capturar uma venda e seu pagamento em dinheiro
Resumo:		Um cliente chega ao caixa com itens a comprar.
		O caixa registra os itens comprados e recebe pagamento.
		No fim, o cliente sai com os itens comprados.
Tipo:		primário e essencial
Referência cruzada: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1
		(pode fazer referência a outros use Cases)
Sequência típica de eventos
	Ação do ator
	Resposta do sistema
	1. O Use Case inicia quando um cliente chega a um caixa munido de TPDV com itens a comprar
	2. 
	2. O caixa registra a identificação de cada item
Se houver mais itens, o caixa pode informar a quantidade também
	3. Determina o preço do item e adiciona a informação ao total da transação de venda
A descrição e preço do item corrente são exibidos
	4. Ao completar a entrada dos itens, o caixa indica este fato ao TPDV
	5. Calcula e apresenta o total da venda
	6. O caixa informa o total da venda ao cliente
	7. 
	7. O cliente efetua o pagamento com dinheiro, possivelmente maior que o total da venda
	8. 
	8. O caixa registra a quantidade de dinheiro recebida
	9. Mostra o valor do troco ao cliente
Gera um recibo impresso
	10. O caixa deposita o dineiro recebido e extrai o troco a devolver
O caixa entrega o troco e o recibo impresso ao cliente 
	11. Faz log da venda completada
	12. O cliente sai da loja com os itens comprados
	13. 
Sequências alternativas:
Linha 2: Entrada de um identificador inválido. Indica erro.
Linha 7: Cliente não tinha dinheiro suficiente. Cancela transação de venda.
Atores
· Um ator é uma entidade externa ao sistema que, de alguma forma, participa das estórias relatadas no Use Case
· Um ator tipicamente estimula o sistema com eventos de entrada ou recebe algo so sistema
· Atores são representados pelo papel que desempenham (e não por nome de pessoa, etc.)
· Em UML, o ícone que representa um ator é o seguinte:
· Para cada Use Case, um dos atores é o iniciador e outros atores podem ser participantes
· Atores correspondem frequentemente a papeis de seres humanos mas, às vezes, outros sistemas ou dispositivos elétricos ou mecânicos podem ser atores
O motivo de usar Use Cases
· Para decidir e descrever a funcionalidade de comum acordo com o cliente
· Servem de documento básico de referência durante todo o processo sobre o que foi prometido
· Serve como base para elaborar os testes funcionais do sistema final
· Para poder rastrearrequisitos funcionais dentro dos modelos de análise, projeto e implementação
· Sabemos que requisitos causaram o aparecimento de determinadas soluções
Um erro frequente ao criar Use Cases
· Iniciantes costumam representar cada etapa, operação ou transação como Use Case separado (exemplo: login como Use Case)
· Um Use Case deve representar uma iteração completa e útil para os atores
· Use Cases são geralmente processos inteiros, cabo-a-rabo e normalmente envolvem muitas etapas ou transações
· Eles modelam os Business Processes do negócio
· Etapas comuns a vários Use Cases podem ser agrupados em Use Cases Abstratos, no sentido de minimizar a duplicação de informação
· Falaremos mais sobre isso em outro capítulo
· Exemplos de processo:
· Sacar dinheiro num caixa eletrônico
· Fazer pedido de um produto
· Cadastrar-se num curso numa escola
· Verificar a grafia de um documento num processador de texto
· Atender uma chamada telefônica
Identificação de Use Cases
· De forma geral, deve-se verificar a lista de requisitos levantados e usar técnicas de brainstorming
· Duas formas comuns:
· Foco nos atores
· Identificar os atores relacionados com o sistema
· Para cada ator, identificar os processos que eles iniciam ou dos quais participam
· Para identificar atores, faça as seguintes perguntas sobre o sistema: 
· Quem vai usar a funcionalidade principal do sistema (atores principais)? 
· Quem vai precisar do suporte do sistema para desempenhar suas tarefas do dia-a-dia? 
· Quem deverá manter e administrar o sistema (atores secundários)? 
· Que dispositivos de hardware o sistema precisa manusear? 
· Com que outros sistemas este interage? 
· Quem ou o que tem interesse nos resultados (valores produzidos) do sistema?
· Foco nos eventos
· Identificar os eventos externos aos quais um sistema deve responder
· Relacione os eventos aos atores e Use Cases
Diagramas de Use Case
· Em UML, um diagrama de Use Case tem o formato seguinte:
· O diagrama identifica e relaciona os Use Cases e os relaciona com os atores
· Observe que o diagrama de Use Case determina com precisão o que é o "sistema"
Use Cases Primários, Secundários e Opcionais
· Use Cases primários: representam processos importantes e/ou comuns (comprar itens)
· Use Cases secundários: representam processos menos importantes ou raros (Pedido de reposição de estoque)
· Use Cases opcionais: representam processos que talvez não sejam considerados
Use Cases Essenciais versus Reais
· Use Cases essenciais: possui uma descrição breve, muito abstrata, sem detalhes, sem mencionar tecnologias empregadas (poderia incluir uma frase: "cliente se identifica" sem maiores detalhes porque a forma de identificação pode mudar com tempo e com a disponibilidade de tecnologia)
· Use Cases reais: muito mais concretos, mencionando tecnologias correntemente usadas ("cliente se identifica passando seu Smart Card no leitor")
· Use Cases essenciais são usados mais cedo no processo (antes do design) e Use Cases podem ser transformados em Use Cases reais durante o design
· Durante o processo de desenvolvimento:
· Durante o levantamento de requisitos
· Crie Use Cases em formato de alto nível
· Crie um diagrama de Use Cases, indicando os relacionamentos
· Selecione os Use Cases mais críticos, que deverão influenciar o sistema mais ou que envolvam mais risco e escreva uma versão Expandida Essencial
· Priorize os Use Cases (próximo capítulo)
· Durante a fase de análise
· Escreva uma versão Expandida Essencial dos Use Cases sendo atacados na iteração corrente (se já não estiver pronta)
· Durante a fase de projeto
· Escreva uma versão Expandida Real dos Use Cases sendo atacados na iteração corrente
Estudo de Caso: O sistema TPDV
Identificar o sistema, atores e Use Cases
· O sistema será a combinação de hardware (o terminal) e software executando nele
· Os atores relevantes e alguns processos que eles iniciam são:
	Caixa
	Fecha caixa
	Cliente
	Compra itens
Devolve itens
	Gerente
	Start Up
Shut Down
	Administrador do sistema
	Adiciona novos usuários
Escrever Use Cases em formato de alto nível
Use case:	Comprar item
Atores:		Cliente (iniciador), Caixa
Tipo:		primário
Descrição:	Um cliente chega ao caixa com itens a comprar.
		O caixa registra os itens comprados e recebe pagamento.
		No fim, o cliente sai com os itens comprados.
 
Use case:	Start Up
Atores:		Gerente
Tipo:		primário
Descrição:	Um gerente liga um TPDV para o preparar para uso pelos Caixas.
		O gerente verifica que a data e horas estão corretas.
		O sistema está pronto para uso pelos Caixas
Elaborar um diagrama de Use Cases
Escrever alguns Use Cases no formato Expandido Essencial
· Favor ver livro, seção 6.16.5
Priorizar os Use Cases
· Ver próximo capítulo
plan-3 programa anterior próxima
Priorização de Use Cases
Objetivos
· Priorizar Use Cases
· Quando necessário, criar versões simplificadas de Use Cases
· Alocar os Use Cases às iterações de desenvolvimento
Introdução
· De forma geral, cada iteração da fase de construção vai tratar de um ou mais Use Cases identificados
· Às vezes, um Use Case pode ser tratado em duas ou mais iterações, com versões simplificadas tratadas primeiro
Priorização de Use Cases
· Normalmente, quem prioriza os Use Cases é o cliente (ou Domain Expert)
· Os técnicos podem ajudá-lo fornecendo estimativas de esforço de desenvolvimento para os vários Use Cases
· Mas lembre que é o cliente que sabe o Business Value de cada Use Case
· Alguns parâmetros que podem aumentar a prioridade de um Use Case
· Afetam muito a arquitetura
· O primeiro incremento deveria ser um teste arquitetural (uma validação da viabilidade da arquitetura)
· O processo de desenvolvimento deve ser "architecture-centric"
· Pouco esforço dando muito insight sobre o projeto do sistema
· Use Cases que envolvem muito risco, são críticos no tempo
· O processo de desenvolvimento deve ser "risk-confronting"
· Envolvem business processes fundamentais
· Deixe o cliente falar!
· Podem aumentar significativamente o lucro ou diminuir as despesas/custos
· Deixe o cliente falar!
O estudo de caso
· Uma possibilidade de priorização
	Prioridade
	Use Case
	Justificativa
	Alta
	Comprar itens
	Satisfaz quase todos os critérios de aumento de prioridade
	Média
	Adicionar novos usuários
Login
Devolver itens
	Afeta a segurança
Afeta a segurança
Processo importante; afeta a contabilidade
	Baixa
	Fechamento de caixa
Start Up
Shut Down
	Efeito mínimo na arquitetura
Definição depende de outros Use Cases
Efeito mínimo na arquitetura
· O Use Case Start Up poderia ser feito numa versão mínima se ele for necessário ao funcionamento do resto
· Escalonamento final dos Use Cases no estudo de caso
· Teremos que atacar Comprar Itens na primeira iteração além de uma versão reduzida de Start Up
· Como Comprar Itens é complexo, pode-se quebrá-lo em várias versões incrementais:
· Comprar Itens versão 1:
· Pagamento em dinheiro apenas
· Sem atualização de estoque
· Loja stand-alone, sem integração a uma organização maior
· Entrada manual de UPC, sem leitor de código de barras
· Sem cálculo de impostos
· Sem descontos especiais
· Sem log in
· Sem manutenção de perfil de usuário (preferências, ...)
· Sem controle contábil do valor em caixa
· Recibo não contém informação completa (sem ID do Caixa, ID do TPDV)
· Comprar Itens versão 2: (todas as formas de pagamentos)
· Comprar Itens versão 3: (versão completa)
· As três versões (além dos outros Use Cases) são distribuídas ao longo dos incrementos
plan-4 programa anterior
Início de uma Iteração de Construção
· Para iniciar uma iteração, lembre que certos refinamentos são feitos antes de iniciar a análise detalhada da funcionalidade desejada na iteração
· O capítulo que inicia agora trata de análise, ou da elaboração de um modelo conceitual
    
Elaboração de um Modelo Conceitual
Objetivos
· Criar um modelo conceitual inicial
· Distinguir entre atributos corretos e incorretos
· Adicionar conceitos de descrição, quando apropriado
· Comparar e contrastar os termos conceito, tipo, interface e classe
Introdução
· O modelo conceitual é oartefato mais importante criado durante a análise
· O modelo conceitual ilustra os conceitos importantes do domínio do problema, suas associações e atributos
· Falaremos de associações e atributos nos próximos capítulos
· Levantar um conjunto rico e expressivo de conceitos (objetos) durante a análise ajuda muito a conduzir as fases de projeto e implementação
· É importante lembrar que os conceitos levantados aqui são do domínio do problema e não conceitos associados a software
Modelos conceituais
· Ao fazer análise OO, a decomposição do domínio do problema utiliza objetos e não funções ou processos como na análise estruturada
· Exemplo de um modelo conceitual (com conceitos, associações e atributos)
· Apenas a parte diagramática está sendo mostrada
· UML permite associar descrições mais detalhadas dos conceitos, atributos, etc.
· Criar o modelo conceitual ajuda a elaborar o glossário, definindo os termos importantes do domínio do problema
· Muito importante para a comunicação entre os envolvidos (clientes e desenvolvedores)
· Modelos conceituais não representam entidades de software mas conceitos do domínio do negócio
· Exemplo correto
· Exemplos errados
· Cuidado! Alguns profissionais acham correto introduzir responsabilidades (ou operações) no modelo conceitual
· Embora ninguém ache certo introduzir métodos (que implementam operações) no modelo conceitual
Estratégias para identificar conceitos (objetos)
· Regra fundamental: é melhor ter conceitos demais (muitos conceitos de granularidade pequena) do que conceitos de menos no modelo conceitual
· Novos conceitos podem ser descobertos com tempo (quando se está identificando associações ou atributos, por exemplo) e a elaboração de um modelo conceitual é portanto uma atividade iterativa
· Na modelagem de dados para bancos de dados, há um critério de modelagem que diz que algo sobre o qual não precisamos lembrar nada não precisa entrar no modelo conceitual
· Com o ponto de visto de persistência, a regra faz sentido
· Mas na modelagem OO, objetos com apenas comportamento (sem atributos) também são importantes (embora raros) e não devem ser excluídos do modelo
Usando a lista de categoria de conceitos
· Conceitos são comumente descobertos nas categorias da tabela seguinte
· Os exemplos são referentes aos domínios de uma loja e reserva de passagem aérea
	Categoria de Conceito
	Exemplos
	Objetos físicos ou tangíveis
	Terminal Ponto De Venda (TPDV)
Aeronave
	Especificações, projetos ou descrições de coisas
	Especificação de produto
Descrição de um vôo
	Lugares
	Loja
Aeroporto
	Transações (um momento notável)
	Venda, Pagamento
Reserva
	Detalhes de transação (Line item)
	Item de detalhe de uma venda
	Papeis de pessoas
	Caixa
Piloto
	Coleções de outras coisas (containers)
	Loja, Prateleira
Aeronave
	Coisas dentro das coleções
	Item
Passageiro
	Outros sistemas externos a nosso sistema
	Sistema de autorização de cartão de crédito
Sistema de controle de tráfego aéreo
	Conceitos abstratos
	Fome
Acrofóbia (medo de altura)
	Organizações
	Departamento de vendas
Voamos Baixo, Ltda.
	Eventos
	Venda, Roubo, Reunião
Vôo, Desastre, Aterrissagem
	Processos (frequentemente não é representado como conceito, mas pode ocorrer)
	Fazer a venda de um produto
Fazer uma reserva de lugar num vôo
	Regras e políticas
	Política de devolução
Política de cancelamento
	Catálogos
	Catálogo de produtos
Catálogo de peças
	Registros de assuntos financeiros, de trabalho, de contratos, legais
	Recibo, Plano de contas, Contrato de emprego
Log de manutenção
	Instrumentos e serviços financeiros
	Linha de crédito
Estoque
	Manuais, livros
	Manual do empregado
Manual de reparos
Achando conceitos através de substantivos
· Uma técnica simples para a identificação de conceitos é de isolar os substantivos nas descrições textuais dos Use Cases
· Muitos dos substantivos serão conceitos ou atributos
· Exemplo: Use Case expandida "Comprar Item com Dinheiro Vivo"
	Ação do ator
	Resposta do sistema
	1. O Use Case inicia quando um cliente chega a um caixa munido de TPDV com itens a comprar
	2. 
	2. O caixa registra a identificação de cada item
Se houver mais itens, o caixa pode informar a quantidade também
	3. Determina o preço do item e adiciona a informação ao total da transação de venda
A descrição e preço do item corrente são exibidos
	4. Ao completar a entrada dos itens, o caixa indica este fato ao TPDV
	5. Calcula e apresenta o total da venda
	6. O caixa informa o total da venda ao cliente
	7. 
	7. O cliente efetua o pagamento com dinheiro, possivelmente maior que o total da venda
	8. 
	8. O caixa registra a quantidade de dinheiro recebida
	9. Mostra o valor do troco ao cliente
Gera um recibo impresso
	10. O caixa deposita o dinheiro recebido e extrai o troco a devolver
O caixa entrega o troco e o recibo impresso ao cliente 
	11. Faz log da venda completada
	12. O cliente sai da loja com os itens comprados
	13. 
· Alguns desses substantivos são conceitos (objetos), outros são atributos de conceitos
· Falaremos mais sobre as diferenças em outro capítulo
· Uma regra útil: Se pensarmos sobre um conceito X como número ou texto no mundo real, ele pode ser um atributo; caso contrário, sempre será um conceito
· Na dúvida, crie um conceito separado
· Exemplo: Destino é um atributo de um vôo ou um conceito separado?
· É um conceito separado (pensamos no destino como sendo um aeroporto)
Conceitos candidatos para o domínio do TPDV
· Usando as técnicas acima, temos a seguinte relação de candidatos:
	TPDV
	Especificação de produto
	Item
	Item de detalhe de uma venda
	Loja
	Caixa
	Venda
	Cliente
	Pagamento
	Gerente
	Catálogo de produtos
	 
Relatórios são objetos?
· Um recibo é um relatório
· Deveria ser um conceito (objeto)
· A favor de excluir:
· Um recibo é apenas um relatório de uma venda
· Incluí-lo no modelo conceitual não seria útil porque toda sua informação é derivada de outros objetos
· A favor de incluir
· Um recibo tem um papel importante nas regras de negócio porque permite que o cliente devolva itens comprados
· Na primeira iteração de desenvolvimento, os Use Cases não consideram a devolução do produto e não incluiremos o objeto Recibo
· Em outra iteração, poderá ser incluído
Modelagem do mundo não real
· Em certos domínios de problema, os conceitos são muito abstratos
· Exemplo: domínio de redes de computadores ou telecomunicações
· Conceitos possíveis são: Mensagem, Conexão, Diálogo, Protocolo, etc.
Modelando descrições
· Não se deve incluir como atributos descrições de conceitos a instâncias desses conceitos por dois motivos
· Repetição de informação
· A descrição some se não houver instância
· Exemplo: Não está correto incluir a descrição de um produto no conceito Produto
· É melhor criar um novo conceito DescriçãoDeProduto que descreve instâncias de Produtos
· Outro exemplo: O conceito Vôo deveria incluir toda a descrição do vôo?
· Não! Se nenhum vôo RG321 ocorrer, a descrição do vôo RG321 deve continuar em algum lugar: é um conceito à parte
Termos empregados na UML
· UML não emprega a palavra "conceito"
· As alternativas são tipo e classe
· A diferença entre tipo e classe é que um tipo é abstrato (sem implementação) enquanto a classe sempre inclui alguma implementação
· Portanto, o tipo é uma especificação e a classe é uma implementação (de um tipo)
· A diferença entre as duas coisas se torna mais importante durante a fase de Projeto
· Por enquanto, basta dizer que usaremos "conceito" para falar do domínio do problema e "classe" para falar de entidades de software
anal1-1 programa próxima
Modelo Conceitual: Adição de Associações
· Ainda estamos em Análise
    
Objetivos
· Identificar associações num modelo conceitual
· Diferenciar associações de conhecimento e associações de entendimento de modelo
Introdução
· Queremos associar conceitos de forma a:
· Satisfazer as necessidades de acesso a informação dos conceitos
· Deixar o modelo conceitual mais fácil de entender
Associações
· Uma associação é um relacionamento estrutural entre conceitos que indicauma conexão interessante e útil
· Critério de associações úteis
· Associações "de conhecimento" (need-to-know) representam a conhecimento de um relacionamento que deve ser preservado por algum tempo
· Entre quais objetos precisamos ter memória de um relacionamento?
· Exemplo: Um "Item de detalhe de uma venda" tem uma associação com uma instância de uma Venda
· Caso contrário, não poderíamos calcular o total da venda, emitir o recibo, etc.
· Vão implicar em algum tipo de navegação no projeto e na implementação
· Outras associações que podem ser úteis são aquelas que melhoram o entendimento do modelo conceitual
Notação UML para associações
· Associações são sempre bi-direcionais
· Não há informação de navegabilidade num modelo conceitual
· Conceitualmente, a navegabilidade existe nos dois sentidos
· Escolher o verbo para representar uma direção ou outra é arbitrário
· Prefere-se manter a voz ativa no verbo
· É melhor "Registra-a-atual" do que "É-registrada-por"
· Não há implicação sobre a existência de ponteiros, chaves estrangeiras, etc.
· A seta de direção de leitura é opcional e indica como ler o nome da associação
· A seta não possui informação semântica
· Pode haver informação de multiplicidade nas extremidades das associações
Como achar associações: a lista de associações comuns
· Os exemplos são dos domínios de uma Loja e da reserva de passagem aérea
	Categoria de Associação
	Exemplos
	A é uma parte física de B
	Gaveta-TPDV
Asa-Aeronave
	A é uma parte lógica de B
	Item de detalhe de vanda-Venda
Trecho de vôo-Rota de vôo
	A é fisicamente contido em B
	TPDV-Loja, Item-Prateleira
Passageiro-Aeronave
	A é logicamente contido em B
	Descrição de item-Catálogo
Vôo-Schedule de vôo
	A é uma descrição de B
	Descrição de item-Item
Descrição de vôo-Vôo
	A é uma linha de detalhe de uma transação ou relatório B
	Item de detalhe de vanda-Venda
Tarefa de manutenção-Log de manutenção
	A é conhecido/logado/registrado/reportado/capturado por ou em B
	Venda-TPDV
Reserva-Lista de passageiros
	A é um membro de B
	Caixa-Loja
Piloto-Viação aérea
	A é uma subunidade organizacional de B
	Departamento-Loja
manutenção-Viação aérea
	A usa ou gerencia B
	Caixa-TPDV
Piloto-Aeronave
	A se comunica com B
	Cliente-Caixa
Agente de reserva-Passageiro
	A está relacionado com uma transação B
	Cliente-Pagamento
Passageiro-Ticket
	A é uma transação relacionada com outra transação B
	Pagamento-Venda
Reserva-Cancelamento
	A é vizinho de B
	TPDV-TPDV
Cidade-Cidade
	A pertence a B
	TPDV-Loja
Aeronave-Viação aérea
· Algumas categorias de associações sempre são úteis num modelo conceitual
· A é uma parte física ou lógica de B
· A está fisicamente ou logicamente contido em B
· A é registrado em B
Nível de detalhamento das associações
· Não inclua associações demais no modelo
· É muito mais importante achar conceitos do que associações
Nomes de associações
· Use uma frase com verbo que facilite a leitura quando juntada com os conceitos em cada extremidade
· Exemplo: Loja Estoca Item
· Associações são normalmente lidas da esquerda para a direita e de cima para baixo
Associações múltiplas entre dois tipos
· Exemplo segue
Associações e implementação
· Durante a análise associações não implicam em fluxos de dados ou informação de navegabilidade
· A implementação de uma associação será frequentemente uma referência entre dois objetos
· Porém, algumas associações da análise não serão implementadas
· Novas associações que forem implementadas (na fase de implementação) devem ser adicionadas ao modelo conceitual (foram esquecidas durante a modelagem conceitual)
Associações no Domínio do TPDV
· Usam-se as duas técnicas mostradas acima para identificar associações
· Associações de conhecimento (que implicam que um objeto deve conhecer o outro)
· Usando a lista de associações comuns
Associações de conhecimento na loja
· As seguintes associações são do tipo "conhecimento"
	Associação
	Por que implica em conhecimento
	TPDV Captura Venda
	Para poder conhecer a venda corrente, calcular o total e imprimir um recibo
	Venda Paga-com Pagamento
	Para poder saber se a venda foi paga, comparar o valor recebido do cliente com o total e imprimir um recibo
	CatálogoDeProduto Registra EspecificaçãoDeItem
	Para poder obter uma especificação de item, dado um código UPC
Usando a lista de associações comuns
· Examinemos a aplicabilidade de cada categoria
	Categoria de Associação
	Sistema TPDV
	A é uma parte física de B
	não se aplica
	A é uma parte lógica de B
	Item de detalhe de venda-Venda
	A é fisicamente contido em B
	TPDV-Loja
Item-Loja
	A é logicamente contido em B
	Especificação de produto-Catálogo de produtos
Catálogo de produto-Loja
	A é uma descrição de B
	Especificaão de produto-Item
	A é uma linha de detalhe de uma transação ou relatório B
	Item de detalhe de venda-Venda
	A é conhecido/logado/registrado/reportado/capturado por ou em B
	Venda (completada)-Loja (é logada por)
Venda (atual)-TPDV (é capturada por)
	A é um membro de B
	Caixa-Loja
	A é uma subunidade organizacional de B
	não aplicável
	A usa ou gerencia B
	Caixa-TPDV
Gerente-TPDV
Gerente-Caixa (mas provavelmente não aplicável no sistema)
	A se comunica com B
	Cliente-Caixa
	A está relacionado com uma transação B
	Cliente-Pagamento
Caixa-Pagamento
Reserva-Cancelamento
	A é uma transação relacionada com outra transação B
	Pagamento-Venda
	A é vizinho de B
	TPDV-TPDV (mas provavelmente não aplicável no sistema)
	A pertence a B
	TPDV-Loja
O modelo conceitual para o domínio TPDV
· Ver modelo conceitual parcial (sem atributos) abaixo
· Pode-se debater cada associação para verificar a utilidade de ser incluída no modelo
· Uma associação que implica conhecimento normalmente fica
· As demais ficam se esclarecerem o modelo
· Não há modelo único "correto"
· Podemos argumentar que algumas associações do modelo poderiam sumir
· Exemplos
· Nenhuma das associações seguintes implica em conhecimento
· Venda Entrada-por Caixa
· Isso mudaria se precisássemos da identificação do caixa no recibo
· TPDV Iniciado-por Gerente
· Venda Iniciada-por Cliente
· Loja Estoca Item
· LinhaDetalheVenda Registra-Venda-de Item
anal1-2 programa anterior próxima
Modelo Conceitual: Adição de Atributos
· Ainda estamos em Análise
    
Objetivos
· Identificar atributos num modelo conceitual
· Distinguir entre atributos corretos e incorretos
Introdução
· Precisamos identificar os atributos que servirão para satisfazer as necessidades de informação dos Use Cases sob consideração na iteração corrente
· Lembre que os atributos são do domínio do problema
Atributos
· Um atributo é um valor de dado lógico de um objeto (ou instância de conceito)
· Os atributos são identificados primariamente localizando a necessidade de lembrar informação
· Exemplo: Uma Venda tem atributos data e hora
Notação UML para atributos
· Os tipos podem ser opcionalmente mostrados
Atributos válidos
Manter os atributos de tipos simples
· Atributos são normalmente de tipos básicos
· Boolean, Date, Number, String (ou Text), Time
· Podem ser de outros tipos comuns tais como
· Endereço, Cor, Geométricos (Point, Rectangle, ...), Fone, CPF, UPC (Universal Product Code), SKU (Stock Keeping Unit), CEP
· Não se deve representar associações como atributos
· Repetição de um exemplo anterior em que um destino de vôo não é um atributo
Valores puros de dados
· Um valor é puro quando não possuem identidade
· Não precisamos distinguir entre instâncias de mesmo valor
· Exemplos: não precisamos distinguir entre
· Instâncias separadas do Number 5
· Instâncias separadas do String "mamãe"
· Instâncias separadas de Fone contendo o mesmo número de telefone
· Instâncias separadas de Endereço contendo o mesmo endereço
· Por outro lado, duas Pessoas chamadas "Sicrano da Silva" devem ser distinguida (têm identidade diferente), apesar do nome igual
· Resultado: apenas um valor puro de dado pode ser representado como atributo
Não usar chaves estrangeiras como atributos
· Na construção de esquemas lógicos de bancos de dados, é comum usar chaves estrangeirascomo atributos
· Isso não deve ser feito num modelo conceitual (OO ou não)
· Exemplo
Uso de tipos não primitivos
· Pode-se escolher entre usar tipos não primitivos que representem valores puros como associação ou como atributo, conforme o desejo do analista ou a situação particular
· O importante é que a comunicação das idéias sobre o modelo esteja clara
· Exemplo
Modelagem de quantidades e unidades
· Cuidado! Certos atributos parecem "números" mas podem ter algo mais associado
· Valores financeiros podem ter uma moeda, além do valor
· Uma quantidade pode ter uma unidade (velocidade em km/s), além do valor
Atributos para o sistema TPDV
· Só estamos considerando os Use Cases da primeira iteração
· Para achar os atributos, lêem-se os requisitos, Use Cases da iteração, outros documentos explicativos
· Muitos atributos poderão não ser descobertos na análise e serão identificados apenas no projeto ou na implementação
· Podemos ver o modelo conceitual final com os atributos abaixo
anal1-3 programa anterior próxima
Construção do Glossário
· Ainda estamos em Análise
    
Objetivos
· Expressar termos num glossário
Introdução
· Um glossário é um documento simples que descreve termos
· A definição de termos do domínio do problema é importantíssimo para manter limpa a comunicação entre desenvolvedores e clientes
· Para reduzir o risco de falahas de entendimento
· Para ajudar a introduzir novos membros na equipe no meio do projeto
· O glossário é elaborado em paralelo com outras fases e é elaborado ao longo da vida do projeto
· Pode incluir definições de tipos, business rules, Use Cases, atributos, etc.
· Eu particularmente não gosto de repetir informação aqui que esteja em outro lugar
· Exemplo: descrição de atributos que poderão estar em outro documento
· Serve como dicionário particular do projeto
Exemplo de glossário (incompleto) para o domínio TPDV
	Termo
	Categoria
	Comentário
	Comprar Itens
	Use Case
	Descrição do processo que envolve a compra de itens por um cliente numa loja
	EspecificaçãoProduto.descrição
	atributo
	Uma descrição curta de um item de venda
	Item
	tipo
	Um item à venda numa Loja
	Pagamento
	tipo
	Um pagamento em dinheiro vivo
	LinhaDetalheVenda.quantidade
	atributo
	A quantidade de um tipo de item comprado
	Venda
	tipo
	Uma transação de venda
	LinhaDetalheVenda
	tipo
	O detalhamento da venda de um item particular numa Venda
	Loja
	tipo
	O lugar onde vendas de itens ocorrem
	Venda.total
	atributo
	O valor total de uma Venda
	EspecificaçãoProduto.UPC
	atributo
	O Universal Product Code do item
anal1-4 programa anterior próxima
Comportamento Dinâmico: Diagramas de Sequência
· Ainda estamos em Análise
    
Objetivos
· Identificar eventos e operações do sistema
· Criar diagramas de sequência do sistema para Use Cases
Introdução
· O modelo conceitual visto no capítulo anterior é um modelo estático
· Agora, vamos considerar um modelo do comportamento dinâmico do sistema
· Um diagrama de sequência do sistema ilustra eventos partindo de atores e estimulando o sistema
· Como ainda estamos investigando o que o sistema faz (e não como), tais diagramas fazem parte do modelo de análise
· Cuidado! Embora o autor do livro texto (Larman) indique que diagramas de sequência do sistema são utilizados apenas na análise, eles podem ser utilizados no projeto também
· Os diagramas de sequência do sistema são altamente dependentes dos Use Cases, pois é a partir deles que criamos os diagramas
· Trataremos o sistema como "caixa preta", isto é, investigando o que ele faz, mas não como
Diagramas de sequência do sistema 
· Os Use Cases sugerem como atores interagem com o sistema
· Os atores geram eventos para o sistema, pedindo que alguma operação   seja feita
· Exemplo: quando o caixa entrega o UPC do item sendo comprado ao sistema, o caixa pede que o sistema registre a compra deste item
· Queremos entender o sistema melhor examinando as operações que um ator requisita do sistema
· Um diagrama de sequência do sistema mostra, para um cenário particular de um Use Case, os eventos gerados pelos atores externos, sua ordem, além de eventos envolvendo outros sistemas
· Todos os sistemas são tratados como caixas preta
· Portanto, os eventos cruzam fronteiras de sistemas
· Diagramas de sequência do sistema são elaborados para os Use Cases mais importantes e as alternativas mais cruciais dos Use Cases
· Cuidado! Não gere diagramas de sequência do sistema para situações óbvias ou de fácil entendimento
Exemplo de um diagrama de sequência
· No diagram abaixo, o tempo flui para baixo
· Eventos podem incluir parâmetros
Operações do sistema
· Para cada evento, há uma operação correspondente que o sistema desempenha
· Podemos enxergar o sistema como possuindo operações, necessárias para descrever um comportamento dinâmico
· No modelo conceitual, isso não era necessário pois estávamos descrevendo um modelo estático
· Exemplo:
Mostrando o texto dos Use Cases nos diagramas de sequência
· Útil para mostrar a relação entre as operações e a descrição dos Use Cases
· Exemplo:
· Cuidado! Só utilize diagramas de sequência para esclarecer iterações mais complexas entre os atores e o sistema
· O exemplo mostrado aqui é simples demais e não merece um diagrama de sequência
anal1-5 programa anterior próxima
Comportamento Dinâmico: Contratos
· Ainda estamos em Análise
    
Objetivos
· Criar contratos para as operações do sistema
Introdução
· Estamos continuando a investigar o comportamento dinâmico do sistema
· Contratos descrevem os efeitos que as operações têm no sistema
· Em UML, contratos são especificados usando pré-condições e pós-condições
· Contratos são estabelecidos depois temos o modelo conceitual, que fizemos os diagramas de sequência e que identificamos as operações no sistema
· Continuamos com uma visão de caixa preta para o sistema (queremos caracterizar o que o sistema faz e não como o faz)
Contratos
· O diagrama de sequência não menciona a funcionalidade das operações
· Isto é, o comportamento do sistema
· Um contrato é um documento que descreve o que uma operação promete cumprir
· As pré- e pós-condições descrevem as mudanças de estado do sistema
· Contratos podem ser associados a operações do sistema como um todo ou a métodos individuais (na fase de projeto)
· Consideraremos apenas contratos de operações de sistema
Exemplo de um contrato
Segue um contrato possível para a operação entrarItem
	Nome
	entrarItem(upc:número, quantidade:integer)
	Responsabilidades
	Registrar a venda de um item a adicionar seu valor ao total da venda.
Exibir a descrição do item e seu preço
	Tipo
	Sistema
	Referências cruzadas
	Funções do sistema: R1.1, R1.3, R1.9
	Anotações
	
	Exceções
	Se o UPC não for válido, indicar erro
	Saída
	Faz log da venda completada
	Pré-condições
	UPC é conhecido pelo sistema
	Pós-condições
	· Se for uma nova venda, uma Venda foi criada (criação de instância)
· Se for uma nova venda, a nova Venda foi associada ao TPDV (formação de associação)
· Uma LinhaDetalheVenda foi criada (criação de instância)
· A LinhaDetalheVenda foi associada à Venda (formação de associação)
· LinhaDetalheVenda.quantidade recebeu o valor quantidade (mudança de atributo)
· A LinhaDetalheVenda foi associada com uma EspecificaçãoProduto, baseado no casamento de UPC (formação de associação)
· Alguns comentários
· O tipo pode ser Sistema, Classe de software ou Interface, dependendo do tipo de contrato que se está elaborando
· As anotações podem indicar dicar para a fase de projeto, algoritmos especiais desejados, etc.
· A saída indica informação que sai do sistema (mensagens, registros, ...), sem incluir a interface com o usuário
· As pré-condições mencionam as suposições sobre o estado do sistema antes da execução da operação
· Muitas dessas coisas poderão ser testadas durante a implementação (programação defensiva)
· As pós-condições mencionam as alterações ao estado do sistema como resultado da execução da operação (isto, é depois que a operação terminou)
· As pós-condições podem ser descobertas nas seguintes categorias:· Criação e destruição de instâncias
· Modificação de atributos
· Associações formadas e quebradas
· Não mencione ações que são feitas na operação mas mudanças que ocorreram no estado do sistema
· Tire uma foto do sistema antes e depois da operação e descreva a diferença entre as duas fotos
· Descrevemos o que ocorreu e não como ocorreu
· Outros contratos podem ser vistos no livro de Larman
Relação com outros artefatos
anal1-6 programa anterior
Da Análise ao Projeto
· A análise se concentra na questão "O quê?"
· Entendimento dos requisitos, conceitos e operações relacionados a um sistema
· A próxima fase é a de Projeto, onde a questão "Como?" é abordada
· O projeto de um sistema é dividido em duas partes
· Projeto arquitetural (ou Projeto de Alto Nível)
· Projeto detalhado (ou Projeto de Baixo Nível)
· O projeto arquitetural lida com questões "macro"
· O projeto detalhado lida com objetos individuais e suas interações
· Procura-se resolver o problema de atribuir responsabilidades às classes
· Também trata de resolver as questões de persistência de objetos 
· Padrões de Projeto (Design Patterns) são extremamente úteis durante o Projeto detalhado
proj1-1 programa próxima
Projeto Arquitetural
    
Resumo da seção
· Projeto de uma arquitetura
· Decomposição do sistema: partições e camadas
· Arquiteturas em n camadas
· Uso de UML para modelar a arquitetura
· Estruturas de controle
· Opções de persistência
· Reutilização: Frameworks e componentização
· Resumo: Perguntas a fazer ao elaborar um projeto arquitetural
Projeto de uma arquitetura
· O que é um projeto arquitetural?
· Decisões estratégicas que terão consequências profundas
· As decisões são tomadas num alto nível
· Exemplos de decisões
· Modularização do projeto em subsistemas
· Escolha de uma estrutura de comunicação e controle entre os subsistemas
· Escolha da divisão de trabalho entre membros de uma equipe ou entre equipes de desenvolvimento
· Definição das interfaces entre subsistemas para possibilitar o trabalho paralelo de desenvolvimento
· Escolha de uma estratégia de persistência
· Escolha do paradigma de DBMS a usar
· Determinação de oportunidades para o reuso de software
· Atendimento a requisitos especiais de desempenho
· Atendimento a outros requisitos (custo, mobilidade, uso de padrões, etc.)
· Exposição das interfaces para facilitar a futura integração de aplicações (Enterprise Application Integration - EAI)
· etc.
· Observe que sempre deve-se ter um olho na satisfação dos requisitos levantados
· Veremos vários aspectos do projeto arquitetural
· A discussão é direcionada mais a sistemas de informação
Decomposição do sistema: partições e camadas
· Uma estrutura elegante pode frequentemente ser elaborada usando camadas e partições
· Uma camada é um subsistema que adiciona valor a subsistemas de menor nível de abstração
· Uma partição é um subsistema "paralelo" a outros subsistemas
· Lembre que subsistemas devem ser coesos (trata de responsabilidades fortemente relacionadas)
· Tem forte acoplamento dentro de um subsistema
· Tem fraco acoplamento entre subsistemas
· Para minimizar o acoplamento, camadas frequentemente se comunicam apenas com as camadas "vizinhas"
· A decomposição pode terminar quando você atingir subsistemas com temas claros que sejam simples de entender
· Alguns sistemas muito pequenos não necessitam de camadas e partições
Arquiteturas em n camadas
· Para sistemas de informação que incluam uma interface com o usuário e persistência (isto é, quase todos!), usa-se frequentemente uma arquitetura em 3 camadas (3-tier architecture)
· As camadas verticais são:
· Apresentação: janelas, relatórios, etc.
· Também chamada de Camada de Interface com o Usuário, Camada de Serviços do Usuário
· Lógica da Aplicação: tarefas e regras que governam o processo
· Também chamada de Camada de Aplicação, Ccamada de Serviços de Aplicação
· Dados: mecanismo de armazenamento persistente
· Também chamada de Camada de Gerência de Dados, Camada de Serviços de Dados, Camada de Armazenamento
· O que vai em cada camada pode mudar ligeiramente
· Exemplo: é possível (e pode ser desejável) ter alguma lógica de aplicação na camada de dados usando Stored Procedures
· Exemplo: é possível (mas em geral indesejável) ter alguma lógica de aplicação na camada de apresentação usando linguagens de scripts
· Em que máquina cada camada roda pode variar, mas hoje em dia, a distribuição física completa é comum
· Por que uma arquitetura em 3 camadas?
· Sistemas em camadas surgiram para aproveitar os PCs da empresa e oferecer sistemas com interface gráficas amigáveis e integradas ao desktop
· Os primeiros sistemas cliente-servidor eram de duas camadas (juntando as camadas de apresentação e de aplicação) mas sofriam de vários problemas:
· Falta de escalabilidade (conexões a bancos de dados)
· Enormes problemas de suporte (mudanças à lógica de aplicação forçava instalações)
· Nenhum suporte a Thin Clients (PDA, celulares, smart cards, quiosques, ...)
· Dificuldade de acessar fontes heterogêneas (legado CICS, 3270, ...)
· Dificuldade de criar software reutilizável para rodar em clientes
· Além do mais, a arquitetura em 3 camadas permite:
· Usar o browser como cliente universal, levando ao conceito de Intranet
· Evitar instalação em computadores de clientes, parceiros, fornecedores, etc.
· Implementar serviços automáticos de persistência, tolerência a falhas com fail-over, gerência de transações, balanceamento de carga, resource pooling, etc.
· Enterprise JavaBeans, COM+
· Arquitetura em n camadas
· Podemos dividir a camada de aplicação em mais de uma camada
· Frequentemente feito separando as aspectos relacionados ao domínio do problema e os aspectos de serviços
  
· Podemos também dividir a camada de dados em mais camadas (usando um datawarehouse, por exemplo)
Uso de UML para modelar a arquitetura
· UML provê o conceito de package para agrupar elementos
· Este mecanismo pode ser utilizado para evidenciar os subsistemas e suas dependências
· Um package em UML:
· A arquitetura em camadas pode ser representada em UML:
· A arquitetura detalhada e as dependências (acoplamento) entre packages podem ser representadas em UML:
Estruturas de controle
· O paradigma de controle externo da aplicação deve ser escolhido
· O paradigma diz como uma aplicação é controlada "de fora" e como interage com seus usuários e outras aplicações
· O controle interno dos objetos da aplicação não é visível fora da aplicação
· Há vários paradigmas de controle externo
· Controle orientado a procedimento
· Tem um único thread no programa
· Métodos executam chamadas para obter dados de entrada e esperam os dados
· O estado do programa pode ser guardado em variáveis locais aos procedimentos (na pilha de execução)
· Vantagem: fácil de implementar com linguagens convencionais
· Desvantagem: qualquer paralelismo inherente aos objetos deve ser mapeado a um fluxo de controle sequencial
· Frequentemente usado em aplicações que possuem uma interface não gráfica
· Controle orientado a evento
· Um dispatcher é provido pela linguagem, SGBD, linguagem ou sistema operacional
· Métodos da aplicação são amarrados a eventos
· Quando o evento ocorre, o método correspondente é chamado
· Todos os métodos retornam o controle para o dispatcher em vez de esperar que os dados de entrada cheguem
· O estado do programa deve ser guardado em variáveis globais já que os métodos retornam o controle (e não ficam com ele)
· Vantagem: ajuda a separar a lógica da aplicação da interface com o usuário
· Frequentemente usado com SGBD munido de linguagem de quarta geração
· Muito usado com bancos de dados
· Quase sempre usado para controlar uma interface gráfica
· Controle concorrente
· O controle fica com vários objetos autônomos, cada um respondendo a eventos
· A concorrência é provida pelo sistema operacional
· Usando paralelismo em hardware ou não
· Observe que estamos nos referindo a controle concorrente dentro da aplicação e não entre aplicações
· Este último é muito comum (sessões paralelas de acesso a BD, por exemplo)
· Infrequentementeusado, embora seu uso tenda a crescer com o CORBA (framework de objetos distribuídos)
· Controle declarativo
· O programa usa um fluxo de controle implícito beaseado em statements declarativos
· Usado em sistemas especialistas baseados em regras
· Dois padrões de controle frequentemente utilizados na arquitetura são:
· Observer Pattern (ou Publish-Subscribe) para acoplar objetos ou subsistemas
· Model-View-Controller (MVC) para separar os objetos de domínio dos objetos de interface
· Serão descritos em outro capítulo (sobre Design Patterns)
Opções de persistência
· Tratamos aqui apenas dos aspectos arquiteturais da persistência
· Um capítulo à frente trata mais detalhadamente do mapeamento de projetos OO para esquemas de BD relacionais
· Três grandes pontos devem ser tratados com respeito à persistência de objetos:
· Escolha da forma básica de persistência (na memória, em arquivos, usando um SGBD)
· Escolha do paradigma de SGBD (se usar um SGBD)
· Determinação da estratégia de interação entre a aplicação e os dados
Escolha da forma básica de persistência
· As alternativas básicas são:
· Dados na memória
· Dados em arquivos
· Dados sob controle de um BD
· Muitas aplicações requerem necessariamente os serviços de um BD, mas algumas podem funcionar bem com uma alternativa mais simples
· Os seguintes pontos devem ser avaliados para tomar a decisão sobre a forma de persistência:
· Persistência de dados
· Arquivos e SGBDs são fortes
· Ficar com os dados na mamória requer um suporte especial de memória e fontes de alimentação para prevenir a perda de informação
· Custo de aquisição
· Um SGBD pode ser muito caro
· Se houver um site license já em uso, o custo incremental pode ser pequeno
· O hardware para manter dados na memória pode ser caro
· Arquivos nada custam pois são inherentemente suportados pelo sistema operacional
· Custo total de posse (Total Cost of Ownership)
· Custos incluem a aquisição, treinamento, desenvolvimento, implantação, operação e manutenção
· Qualquer uma das 3 alternativas pode ganhar aqui
· Exemplo: SGBD pode reduzir custos de desenvolvimento mas aumenta custos de operação (incluindo recursos humanos)
· Exemplo: arquivos não têm custo de aquisição mas têm um alto custo de manutenção
· Quantidade de dados
· SGBDs podem armazenar gigantescas quantidades de informação
· Recursos de hardware limitam a quantidade de dados que pode ser armazenada na memória
· Arquivos são limitados em tamanho pelo sistema operacional
· Cuidado com sistemas que limitam arquivos a 32 bits (4 GBytes)
· Desempenho
· xdados na memória são acessados mais rapidamente
· SGBDs têm algoritmos e estruturas de dados especiais para lidar com grandes quantidades de dados
· Arquivos podem ser rápidos se couberem na memória ou se forem eficientemente acessados sequencial ou randomicamente
· Extensibilidade
· SGBDs oferecem independência de dados de forma que o desenvolvedor pode se concentrar nos aspectos lógicos dos dados, sem preocupação imediata com detalhes de implementação física
· Acesso concorrente
· A granularidade de travamento pode afetar o desempenho
· Tipicamente, arquivos são travados por completo
· Travamento de registros de arquivos requer muita programação
· A granularidade é melhor com dados na memória
· SGBDs podem ter boa granularidade (record locking) ou menos boa (page locking)
· Além do mais, SGBDs podem escalonar travamentos e resolver conflitos automaticamente sem programação adicional
· Recuperação de crash
· Arquivos: Arquivos de backup são necessários
· SGBDs: têm lógica sofisticada para recuperação de crash
· Memória: requer o uso de shadow memory
· Integridade
· Apenas SGBDs oferecem o suporte a regras de integridade (definidas pelo programador)
· Suporte a transações
· Apenas SGBDs oferecem suporte a transações
· Distribuição
· Apenas (alguns) SGBDs oferecem suporte à distribuição de dados e vários sites
· Linguagem de consulta
· SGBDs oferecem linguagens de consulta para facilitar o manuseio de dados
· Alguns produtos do mercado oferecem linguagens de consulta simples para dados em arquivos
· Segurança
· Arquivos podem ser protegidos pelo sistema operacional (mas sem sofisticaão)
· SGBDs podem implementar segurança com passwords, views, etc.
· Metadados
· SGBDs permitem a manipulação da estrutura dos dados (metadados) em tempo de execução
· Um sumário segue:
	 
	Dados na memória
	Arquivos
	SGBDs
	Persistência de dados
	Requer hardware especial
	Bom suporte
	Bom suporte
	Custo de aquisição
	Custo do hardware especial
	Não há
	Pode ser caro
	Custo total de posse
	Variável
	Variável
	Variável
	Quantidade de dados
	Limitado pelo hardware
	Limitado pelo sostema operacional;
A memória limita files em cache
	Essencialmente sem limite
	Desempenho
	Muito rápido
	Rápido para acesso sequencial, certos acessos randômicos e para arquivos em cache
	Rápido
	Estensibilidade
	Limitada
	Limitada
	Excelente
	Acesso concorrente
	Locking de objetos
	Locking de arquivos
	Locking de objetos ou de registros;
Alguns SGBDs só têm locking de páginas
	Recuperação de crash
	Shadow memory
	Arquivos de backup
	Bom suporte
	Integridade
	Não há
	Não há
	Projetista pode especificar regras
	Suporte a transações
	Não há
	Não há
	Transações curtas
	Distribuição
	Não há
	Não há
	Às vezes
	Linguagem de consulta
	Não há
	Parcial
	Poderosa
	Segurança
	Não há
	Proteção simples do sistema operacional
	Pode ser simples ou sofisticado
	Metadados
	Não há
	Não há
	Sim
· Em suma, algumas aplicações naturalmente se beneficiam de cada alternativa de persistência:
· Dados na memória
· Dados para dispositivos eletrônicos (celulares, PDAs, ...)
· Dados para smart cards, cartuchos de jogos
· Dados para aplicações que não podem tolerar o custo ou falta de confiabilidade de um disco
· Arquivos
· Dados de grande volume, com pouca densidade de informação (archival files, registros históricos detalhados, logs, ...)
· Dados crus que devem ser sumarizados num BD (exe.: aquisição de dados, telemetria, ...)
· Quantidades modestas de dados com estrutura simples (quando não tem SGBD ou este seria complexo demais para a empresa manter)
· Dados acessados sequencialmente
· Dados que são lidos por inteiro na memória
· SGBDs
· Dados que requerem atualização com níveis finos de granularidade por múltiplos usuários
· Dados que devem ser acessados por várias aplicações
· Grandes quantidades de dados que devem ser eficientemente manipulados
· Dados de longa duração e muito valiosos a uma organização
· Dados que devem ser acessados com sofisticado controle de segurança
· Dados sujeitos a análise sofisticada para o apoio à decisão
· Finalmente, observe que é comum utilizar mais do que uma única alternativa para dados diferentes
Escolha do paradigma de SGBD
· Se usar um SGBD, ainda deve-se escolher entre SGBDs relacionais, objeto-relacionais e orientados a objeto
· Os detalhes fogem do escopo desta disciplina
· Resumindo:
· SGBDRs são maduros mas sofrem de um problema sério: impedance mismatch entre objetos e relações
· As grandes desvantagens são:
· Navegação lenta (usando joins de tabelas)
· Protocolos de travamento inflexíveis (por serem automáticos)
· Poucos tipos de dados
· Tudo tem que ser uma tabela
· Mostraremos como mapear um projeto OO para um esquema relacional num capítulo à frente
· SGBDOOs não são tão maduros mas não sofrem de impedance mismatch e apresentam recursos avançados (evolução de esquema, controle de versões, long transactions, notificações de mudanças, ...)
· Oferecem navegação rápida mas ainda carecem até de uma teoria completa!
· Há ainda a alternativa de SGBDs Objeto-Relacionais que mantêm o paradigma relacional mas resolvem algumas questões (tais como melhor suporte a tipos de dados)
Determinação da estratégia de interação entre a aplicação e os dados
· Quais são as estratégias para conectar sua aplicação a um SGBD?
· Pré-processador e pós-processador batch
· Em alguns casos, é melhor que a aplicação não acesse o BD
· Aplicações batch existentes podem fazer uso de um BD de forma indireta
· Pode ser útil em algos (raros?)casos em que se usa software legado ou sem código fonte dentro de uma aplicação (como subsistema)
· Arquivos de script
· Para certas aplicações simples, basta executar um ou mais arquivos contendo comandos de uma linguagem de consulta (SQL, OQL, ...)
· Bom para certas situações tais como criar esquemas, popular um BD, prorotipagem
· Comandos embutidos da linguagem de manipulação de dados de um SGBDOO
· Neste caso, a aplicação acessa o BD diretamente
· Parece natural devido ao casamento entre a linguagem hospedeira (digamos Java) e um SGBDOO
· Cuidado! Ao proceder assim,  o acoplamento com o SGBDOO fica muito forte e pode ser difícil mudar de SGBD posteriormente
· Use o padrão ODMG para melhorar a portabilidade
· Comandos SQL estáticos embutidos
· Código SQl estático é conhecido em tempo de compilação
· É relativamente simples de usar, mas:
· Sem muitos cuidados (batching, etc.), pode resultar numa execução lenta
· Acopla muito o código da aplicação ao esquema do BD
· Resulta em código difícil de se ler
· Em suma, tenta-se desta forma resolver o impedance mismatch com código estático
· Implementar uma API customizada de acesso aos dados
· Os acessos ao BD são encapsulados em poucos métodos da aplicação
· Ajuda a manter a consistência dos dados
· Ajuda a manter o escopo de transações
· Ajuda a não contaminar a aplicação com um monte de código de acesso ao BD
· Técnica muito usada
· Métodos armazenados no BD
· Stored procedures
· Boa forma de reuso para várias aplicações
· Certos cuidados ao usar Stored Procedures serão tratados num capítulo posterior sobre persistência
· Cuidado! Stored Procedures não são implementados de forma portável pelos vários SGBDs do mercado
· O padrão SQL não é obedecido pelos fabricantes
· Linguagem de quarta geração
· SGBDRs normalmente vêm com uma linguagem 4GL
· Podem reduzir o esforço de desenvolvimento, mas não são portáveis
· Camada Genérica Orientada a Objeto
· Uma camada OO é escrita para completamente esconder o BD
· Ela pode ser genérica (para qualquer objeto, qualquer aplicação) com bastante esforço
· Geralmente sofre com desempenho
· Interação baseada em Metamodelo
· A camada de acesso ao BD acessa o metamodelo e constroi a consulta dinamicamente
· A consulta resultante acessa o BD
· Solução frequentemente usada com frameworks
· Cuidado! Essa técnica requer muito esforço!
· É melhor usar uma solução pronta, tal como Toplink
· Uso de Middleware
· Os serviços de persistência podem ser obtidos automaticamente usando Middleware
· Enterprise JavaBeans
· COM+
· Vantagem: muitos serviços são obtidos além da persistência:
· Gerência de transações distribuídas
· Directory/Naming
· Segurança
· Tolerância a falha com Failover
· Balanceamento de carga
· Resource pooling
· Monitoring, logging, ...
Reutilização: Frameworks e componentização
· Devido à sua importância, dedicamos um capítulo à frente sobre o tema de reutilização
· Frameworks
· Criação de uma aplicação quase pronta que permite rapidamente criar várias aplicações de um mesmo domínio de problema
· Componentes
· Pedaços de software que permitem a composição visual de aplicações em tempo de design
Resumo: Perguntas a fazer ao elaborar um projeto arquitetural
Sobre entidades externas ao sistema
· Quais sistemas externos devem ser acessados?
· Como serão acessados?
· Há integração com o legado a ser feita? Como?
Determinação de oportunidades para o reuso de software
· Há interesse/conveniência/tempo em aproveitar tais oportunidades?
· Como isso pode ser feito?
· Com componentes?
· Construindo um framework?
Sobre a organização geral do sistema
· O sistema é centralizado ou distribuído?
· Como modularizar em subsistemas?
· Como minimizar acoplamento entre os pedaços?
· Lembrando que um sistema pode ser visto como sendo composto de três grandes camadas lógicas ...
· Tais camadas serão lógicas ou terão existência física separada?
· Onde colocar o business logic (como dividir entre as camadas)?
· Qual é o nível de acoplamento, frequência de interações, volumes de dados trocados entre as camadas?
· Qual seria a estrutura de comunicação e controle entre os subsistemas (como ligar as camadas)?
· Usando o Observer Pattern?
· Usando o Model-View-Controller Pattern?
· Quais são as interfaces importantes entre os pedaços?
· Qual é o formato das mensagens (xml, ...)?
· Como é feita a comunicação remota? CORBA? RPC? RMI? Message Queue?
· A programação será feita com qual paradigma? OO?
· Que linguagens e ferramentas serão usadas?
Sobre a camada de interface
· O sistema será acessado usando que tipos de clientes?
· Browser?
· Uso de applet?
· Uso de script cliente?
· Como fazer a interface gráfica?
· Com que ferramentas?
· Com que componentes visuais?
· Serão desenvolvidos? comprados?
· Javascript ou outra linguagem de script do lado cliente será usada?
· Que modelo de componentes visuais será usado?
· Activex?
· Javabeans?
· Se a interface usar um browser, como será feita a geração de HTML dinâmico?
· Servlets?
· JSP?
· ASP?
· Que ferramentas usar para a formatação de relatórios?
· Há packages a desenvolver que poderiam ser comuns a várias partes da interface?
Sobre a camada de lógica da aplicação
· Escolha de middleware: qual modelo de componentes de servidor será usado?
· COM+?
· EJB?
· Quais são os componentes principais a fazer?
· Serão componentes persistentes?
· Serão componentes com ou sem estado?
· De que forma atender aos requisitos para uso multiusuário?
· Soluções para resolver a concorrência
· Que APIs serão usadas para acesso a:
· Dados persistentes?
· Serviço de mail?
· Serviço de nomes?
· Há packages a desenvolver que poderiam ser comuns a várias partes da lógica da aplicação?
· Qual é a organização interna dos modulos executáveis?
· Determinar sub-camadas e partições
· Quais são as interfaces importantes entre os pedaços?
· Onde verificar os business rules?
· No SGBD?
· No middleware?
· Como implementar aspectos de segurança?
· Como implementar os requisitos de auditoria?
Sobre a camada de dados persistentes
· Quais são as fontes de dados? externas? internas? existentes? novas?
· Como acessa-las?
· Que estratégia de persistência será usada:
· Na memória (com recursos especiais como pilha)?
· Em arquivos?
· Usando um SGBD?
· Qual paradigma de SGBD usar?
· Relacional?
· O-R?
· O-O?
· Onde usar stored procedures para implementar os business rules ou garantir a integridade dos dados?
· Qual será a estratégia de interação entre a aplicação e os dados?
· De que forma atender aos requisitos para uso multiusuário (concorrência)?
· Como resolver o impedance mismatch entre a camada de lógica de aplicação e o esquema de persistência?
· Para grandes escalas, como oferecer connection pooling?
· Como implementar a segurança no SGBD?
· Como será feita a população dos bancos de dados?
Sobre requisitos de desempenho
· Há necessidade de bolar formas especiais de atender aos requisitos de desempenho?
· Como prover escala?
· Como prover failover?
O que deve ser produzido?
· Quais são os módulos executáveis a produzir?
· Executáveis, DLLs, ...
· Quais são os arquivos importantes (de configuração, etc.) e seu formato (xml, ...)?
· Como será resolvida a instalação do produto?
· O que será comprado, feito, modificado?
· O que será gerado automaticamente com uma ferramenta especial?
· Exemplo: geração de esquema através de ferramentas CASE, ...
Sobre a integração futura
· Que interfaces devem ser expostas para facilitar a futura integração de aplicações (Enterprise Application Integration - EAI)?
· Pode-se usar uma camada de API para expor a camada de business logic, colocar uma camada de script acima disso e ainda camada(s) de interface para ativar a business logic através de scripts.
· Vantagens:
· Fácil criação de macros e outras formas de automação
· Fácil criação de testes de regressão
· Clara separação de business logic da interface para o usuário
· Como será feita a exposição?
· Com XML?
· Através de uma API?
Perguntas adicionais
· Que ferramentas de desenvovimento serão geradas?
· Como será o atendimento a outros requisitos (custo,