professor mário dantas
DESCRIPTION
Engenharia de Software. Set/2010. Professor Mário Dantas. Aula 04- Agenda. Princípios e conceitos de análise e projeto;. MODELAGEM DE ANÁLISE. - PowerPoint PPT PresentationTRANSCRIPT
Professor Mário DantasSet/2010
ENGENHARIA DE SOFTWARE
2
Aula 04- Agenda Princípios e conceitos de análise e
projeto;
3
Durante as últimas décadas, um grande número de métodos de modelagem de análise foi desenvolvido. Pesquisadores identificaram problemas de análise e suas causas, e desenvolveram uma variedade de notações de modelagem e conjuntos de heuríticas correspondentes para resolve-los. Cada método de análise tem um ponto de vista singular. No entanto, todos os métodos de análise estão relacionados a um conjunto de princípios operacionais (PRESSMAN, 2006).
MODELAGEM DE ANÁLISE
4
O que é?
A modelagem da análise usa uma combinação de formas textuais e diagramáticas para mostrar os requisitos de dados, função e comportamento, de modo que seja relativamente fácil de entender e revisar o sistema.
5
Quem faz?
Um engenheiro de software (ou analista) constrói um modelo usando requisitos extraídos do cliente.
6
Por que é importante?
Por representar os requisitos de várias maneiras, aumentando a chance de serem encontrados erros, inconsistências e que omissões sejam descobertas.
7
Qual é o produto do trabalho?
Uma variedade de formas diagramáticas podem ser escolhidas para o modelo de análise. Cada uma fornece uma visão de um ou mais elementos do modelo.
8
Como tenho certeza de que fiz corretamente?
Revisados quanto à correção, completeza e consistência.
Devem refletir as necessidades dos interessados e estabelecer um fundamento com base na qual o projeto pode ser conduzido.
9
Princípios da Modelagem de Análise
O domínio da informação de um problema deve ser representado e entendido;
As funções a serem desenvolvidas pelo software devem ser definidas;
O comportamento do software (como conseqüência de eventos externos) precisa ser representado.
O modelos que mostram informações, funções e comportamento devem ser particionados de um modo que revele detalhes em forma de camadas (ou hierarquias);
A tarefa de análise deve ir da informação mais essencial até os detalhes de implementação.
10
Conjunto genérico de Tarefas para modelagem de Análise
Revisar os requisitos de negócio, as características/necessidades dos usuários, as saídas visíveis ao usuário, as restrições do negócio e outros requisitos técnicos que foram determinados durante a atividade de comunicação com o cliente e o planejamento.
11
Conjunto genérico de Tarefas para modelagem de Análise
Expandir e refinar os cenários do usuário. Definir todos os atores; Representar como os atores interagem com
o software. Extrair funções e características dos
cenários de usuário. Revisar o cenário do usuário quanto à
completude e precisão.
12
Conjunto genérico de Tarefas para modelagem de Análise
Modelar o domínio da informação. Representar todos os principais objetos de
informação; Definir atributos para cada objeto de
informação; Representar os relacionamentos entre os
objetos de informação.
13
Conjunto genérico de Tarefas para modelagem de Análise
Modelar o domínio funcional. Mostrar como as funções modificam os
objetos de dados; Refinar funções para fornecer detalhes de
elaboração; Escrever um narrativa de processamento
que descreva cada função e subfunção; Revisar os modelos funcionais.
14
Conjunto genérico de Tarefas para modelagem de Análise
Modelar o domínio comportamental. Identificar os eventos externos que causam
mudanças comportamentais no sistema; Identificar os estados que representam
cada modo de comportamento observável externamente;
Mostrar como o evento faz o sistema se mover de um estado para outro;
Revisar os modelos comportamentais.
15
Conjunto genérico de Tarefas para modelagem de Análise
Analisar e modelar a interface do usuário. Conduzir tarefa de análise; Criar protótipos de imagem de tela;
Revisar todo os modelos quanto à completude, consistência e omissões.
16
O modelo de análise deve:
Descrever o que o cliente exige Estabelecer a base para a criação de um
projeto de software Definir um conjunto de requisitos que possam
ser validados quando o software for construído
17
Regras práticas de Análise O nível de abstração deve ser relativamente
alto. Adie a consideração de modelos de infra-
estrutura e outros não funcionais até o projeto. Minimize o acoplamento ao longo de todo o
sistema Certifique-se de que o modelo de análise tem
valor para todos os interessados Mantenha o modelo tão simples quanto puder
18
Análise de Domínio
É a identificação, análise e especificação dos requisitos comuns de um domínio de aplicação específico.
Sua meta é encontrar ou criar classes de análise e/ou as funções e características que são amplamente aplicáveis, de modo que possam ser reutilizadas.
19
Abordagens de Modelagem de Análise
Elementos baseados em cenários Elementos baseados em classes Elementos comportamentais Elementos orientados a fluxos
20
Atividade 002
4 grupos para apresentar as abordagens de modelagem de análise
Data: 15/09/2010
21 Projeto de Software
22
Objetivos
Conhecer os conceitos relacionados ao projeto de software, bem como sua aplicação;
Saber quais decisões devem ser tomadas sobre a arquitetura de sistema durante o processo de projeto de arquitetura.
23
Projeto de Software
Engloba um conjunto de princípios, conceitos e práticas que levam ao desenvolvimento de um sistema ou produto de alta qualidade.
Seu objetivo é produzir um modelo ou representação que exiba firmeza, comodidade e prazer, ou seja, que satisfaça aos requisitos do sistema.
24
O que é?
O projeto cria uma representação ou modelo de software, mas diferente do modelo de análise (que enfoca a descrição dos dados, função e comportamento requeridos).
O modelo de projeto fornece detalhe sobre as estruturas de dados, arquitetura, interfaces e componentes do software necessários para implementar o sistema.
Projeto de Software
25
Quem faz? Engenheiros de software conduzem cada uma das
tarefas de projeto.
Por que é importante? Permite ao engenheiro de software modelar o
sistema ou produto que deve ser construído. Esse modelo pode ser avaliado quanto à qualidade e aperfeiçoado antes que o código seja gerado, testes sejam conduzidos e usuários finais fiquem envolvidos em grande número.
Projeto de Software
26
Atividades de projeto
27
Atividades de projeto Projeto da Arquitetura do Software� :
visa a definir os grandes componentes estruturais do software e seus relacionamentos.
�Projeto de Dados: tem por objetivo projetar a estrutura de armazenamento de
dados necessária para implementar o software. Projeto de Interfaces:
descreve como o software deverá se comunicar dentro dele mesmo (interfaces internas), com outros sistemas (interfaces externas) e com pessoas que o utilizam (interface com o usuário).
Projeto Procedimental Detalhado: tem por objetivo refinar e detalhar a descrição procedimental
dos componentes estruturais da arquitetura do software.
28
Princípios da Modelagem de Projeto
O projeto deve estar relacionado ao modelo de análise;
Sempre considere a arquitetura do sistema a ser construído;
O projeto dos dados é tão importante quanto o projeto de funções de processamento;
As interfaces (tanto externas quanto internas) precisam ser projetadas como cuidado.
O projeto de interface do usuário deve estar sintonizado com as necessidades do usuário final. No entanto, em cada caso, ele deve enfatizar a facilidade de uso.
29
Princípios da Modelagem de Projeto
O projeto a nível de componente deve ser funcionalmente independente;
Os componentes devem ser fracamente acoplados uns aos outros e ao ambiente externo.
Representações de projeto (modelos) devem ser facilmente compreensíveis.
O projeto de ser desenvolvido iterativamente. A cada iteração, o projetista deve lutar por maior simplicidade.
30
Conjunto genérico de tarefas para o Projeto
Usando o modelo de análise, selecionar um estilo (padrão) arquitetural que seja apropriado para o software.
31
Conjunto genérico de tarefas para o Projeto
Particionar o modelo de análise em subsistemas de projeto e alocar esses subsistemas na arquitetura. Certifica-se de que cada subsistema seja
funcionalmente coesivo. Projetar as interfaces dos subsistemas. Alocar classes ou funções de análise a cada
subsistema. Usando o modelo de domínio de
informação, projetar as estruturas de dados adequadas.
32
Conjunto genérico de tarefas para o Projeto
Projetar as interfaces do usuário. Rever os resultados das análises de tarefas. Especificar a seqüência de ações com base
nos cenário dos usuários. Criar o modelo comportamental da
interface. Definir objetos de interface e mecanismos
de controle. Rever o projeto de interface e revisar
conforme a necessidade.
33
Conjunto genérico de tarefas para o Projeto
Conduzir o projeto em nível de componentes. Especificar todos os algoritmos em um nível
de abstração relativamente baixo. Refinar a interface de cada componente. Definir a estrutura de dados em nível de
componente. Rever o projeto em nível de componente
Desenvolver um modelo de implantação.
34
Qual é o produto do trabalho? Um modelo de projeto que inclui representações de
arquitetura, interface, componente e implantação.
Como tenho certeza de que fiz corretamente? O modelo de projeto é avaliado pela equipe de
software em um esforço para determinar se contém erros, inconsistências ou omissões; se existem alternativas melhores e se o modelo pode ser implementado dentro das restrições, cronograma e custo que foram estabelecidos.
Projeto de Software
35
Projeto de SoftwareObjetivo: produzir um modelo que satisfaça ao requisitos.
Evolução contínua à medida que a análise se aperfeiçoa e entendimento amplia.
36
Projeto serve de base para todas as etapas da Engenharia de Software
Projeto é necessário? Sem projeto, como modificar, testar e avaliar a qualidade?
Permite avaliar a qualidade antes de implementar
Projeto de Software
37
Abstração: visão de alto nível dos aspectos fundamentais do
sistema, de maneira que obtenha-se uma ocultação dos detalhes.
Arquitetura: organização dos componentes de programas, suas
interações e as estruturas usadas pelos componentes. Padrões:
descreve uma estrutura para resolver um determinado problema.
Conceitos de Projeto
38
Modularização Módulos são integrados com o objetivo de
atender a um requisito “Dividir e conquistar”
39
Por que modularizar? Planejar mais fácil Manutenção Testes e depuração Ocultação de Informações Módulos devem ser especificados e
projetados de tal modo que informações desnecessárias sejam inacessíveis
Apenas o necessário é fornecido para a realização de funções
Abstração + ocultação (erros não são propagados nas modificações)
40
Independência FuncionalModularidade + abstração + ocultação = Independência
Funcional
“Finalidade única” e menos interação Interfaces simplificadas Manutenção mais fácil Propagação de erros minimizada Reutilização
Dois critérios (qualitativos) para avaliação COESÃO: robustez funcional de um módulo (módulo
realiza uma única tarefa) ACOPLAMENTO: indicação da interdependência
entre módulos
41
Refinamento e Refatoração Refinamento
Processo de elaboração (alto nível -> mais detalhes)
Refinamentos sucessivos (Abstração + refinamentos): conceitos
complementares
Refatoração Reorganizar para simplificar o projeto sem alterar
as funções e os comportamentos. O que pode ser refatorado?
Redundância, elementos não utilizados, algoritmos ineficientes, etc
42
Extract Method Exemplo Sem Variáveis Locais
void imprimeDivida () {Enumerate e = _pedidos.elementos ();double divida = 0.0;// imprime cabeçalhoSystem.out.println (“***************************”);System.out.println (“*** Dívidas do Cliente ****”);System.out.println (“***************************”);// calcula dívidaswhile (e.temMaisElementos ()){Pedido cada = (Pedido) e.proximoElemento ();divida += cada.valor ();
}// imprime detalhesSystem.out.println (“nome: ” + _nome);System.out.println (“divida total: ” + divida);
}
43
Extract MethodExemplo Com Variáveis Locais
void imprimeDivida () {Enumerate e = _pedidos.elementos ();double divida = 0.0;imprimeCabecalho ();// calcula dívidaswhile (e.temMaisElementos ()){Pedido cada = (Pedido) e.proximoElemento ();divida += cada.valor ();
}//imprime detalhesSystem.out.println(“nome: ” + _nome);System.out.println(“divida total: ” + divida);
}void imprimeCabecalho () { System.out.println (“***************************”);
System.out.println (“*** Dívidas do Cliente ****”);System.out.println (“***************************”);
}
44
Extract MethodExemplo COM Variáveis Locais
void imprimeDivida () {Enumerate e = _pedidos.elementos ();double divida = 0.0;imprimeCabecalho ();// calcula dívidaswhile (e.temMaisElementos ()){Pedido cada = (Pedido) e.proximoElemento ();divida += cada.valor ();
}imprimeDetalhes (divida);
}
void imprimeDetalhes (double divida){
System.out.println(“nome: ” + _nome);System.out.println(“divida total: ” + divida);
}
45
Extract Methodcom atribuição
void imprimeDivida () {imprimeCabecalho ();double divida = calculaDivida ();imprimeDetalhes (divida);
}
double calculaDivida (){
Enumerate e = _pedidos.elementos ();double divida = 0.0;while (e.temMaisElementos ()){Pedido cada = (Pedido) e.proximoElemento ();divida += cada.valor ();
}return divida;
}
46
Extract Methoddepois de compilar e testar
void imprimeDivida () {imprimeCabecalho ();double divida = calculaDivida ();imprimeDetalhes (divida);
}
double calculaDivida (){
Enumerate e = _pedidos.elementos ();double resultado = 0.0;while (e.temMaisElementos ()){Pedido cada = (Pedido) e.proximoElemento ();resultado += cada.valor ();
}return resultado;
}
47 Projeto de Arquitetura
48
Objetivos Introduzir projeto arquitetural e discutir
sua importância. Explicar porque vários modelos são �
necessários para documentar uma arquitetura de software.
Descrever os tipos de modelos �arquitetural que podem ser usados.
49
Arquitetura do Software O processo inicial de projeto, que
consiste em identificar os subsistemas é chamado de projeto de arquitetura.
A saída desse processo de projeto é uma descrição da arquitetura do software.
50
Projeto de Arquitetura Sistemas grandes são sempre decompostos em
subsistemas que fornecem algum conjunto de serviços relacionados.
O projeto de arquitetura é o primeiro estágio no processo de projeto e representa uma ligação crítica entre os processos de engenharia de projeto e de requisitos.
O processo de projeto de arquitetura envolve o estabelecimento de um framework básico que identifica os principais componentes de um sistema e as comunicações entre eles.
51 Comunicação com os stakeholders.
A arquitetura é uma apresentação em alto nível do sistema que pode ser usada para enfocar a discussão entre os diferentes stakeholders.
Análise de sistema. Decisões do projeto de arquitetura tem um profundo
efeito sobre se o sistema pode ou não cumprir requisitos não funcionais importantes (desempenho, confiabilidade, facilidade de manutenção)
Reuso em larga escala. A arquitetura pode ser reutilizada em sistemas com
requisitos similares ou para em um sistema pertencente a uma família de aplicações
Projeto de Arquitetura
52
A arquitetura de sistema afeta o desempenho, facilidade de distribuição e de manutenção de um sistema.
O estilo e a estrutura específicos escolhidos para uma aplicação podem, portanto, depender dos requisitos não funcionais do sistema.
1. Desempenho. 2. Proteção. 3. Segurança. 4. Disponibilidade. 5. Facilidade de manutenção.
Projeto de Arquitetura
Conflitantes
53
Atividades de Processos de projeto de arquitetura Estruturação de sistema
O sistema é decomposto em vários subsistemas principais e a comunicação entre esses subsistemas são identificados.
Modelagem de controle� É estabelecido um modelo geral dos relacionamentos
de controle entre as partes do sistema. Decomposição modular�
Os subsistemas identificados são decompostos em módulos. O projetista deve decidir sobre o tipo de módulo e suas interconexões.
54
Subsistemas e módulos Um subsistema é um sistema cuja
operação não depende de serviços fornecidos por outros subsistema.
Um módulo é um componente do sistema que fornece serviços a outros componentes, mas normalmente não é considerado um sistema independente.
55
Modelos de arquitetura Diferentes modelos de arquitetura pode
ser produzidos durante o processo de projeto.
Cada modelo representa diferentes �perspectivas na arquitetura.
56
O modelo de repositório Subsistemas precisam trocar informações. Isso
pode ser feito de duas maneiras: Dados compartilhados são mantidos em um banco de
dados central, que pode ser acessado por todos os subsistemas.
Cada subsistema mantém seu próprio banco de dados e são passados explicitamente para outros subsistemas.
Quando grandes quantidades de dados precisam �ser compartilhados, o modelo de repositório é usado para organizar os sistemas.
Ex. de sistemas: SIG, CAD, CASE, sistema de �comando e controle
57
Arquitetura de um conjunto de ferramentas CASE integrado
58
Características de um modelo de repositório Vantagens
Maneira eficiente de compartilhar grandes quantidades de dados
Subsistemas que produzem dados não precisam se preocupar em como os dados são utilizados.
Gerenciamento centralizado de atividades, tais como backup,
segurança, etc. O modelo de compartilhamento é visível por meio
do esquema do repositório, facilitando a integração de novas ferramentas (desde que compatíveis com o modelo de dados estabelecido).
59
Características de um modelo de repositório Desvantagens
Subsistemas devem concordar com o modelo de dados de repositório. Inevitavelmente um compromisso.
A evolução de dados é difícil e cara.� Diferentes subsistemas podem ter diferentes
requisitos para políticas de proteção, segurança e backup. O modelo de repositório impõe a mesma política.
Dificuldade em distribuir o repositório em uma �série de máquinas. Pode ser feito, porém pode haver problemas de redundância e inconsistência de dados.
60
Modelo cliente-servidor Modelo cliente-servidor: é um modelo em que o
sistema é organizado como um conjunto de serviços e servidores e clientes associados que acessam e usam os serviços.
Seus componentes são: Um conjunto de servidores que oferecem
serviços para outros subsistemas. Um conjunto de clientes que solicita os serviços
oferecidos pelos servidores. Uma rede que permite aos clientes acessarem
esses serviços.
61
Biblioteca de filmes e fotografias
62
Características de cliente-Servidor Vantagens�
É uma arquitetura distribuída, permitindo o uso efetivo de sistemas de rede com muitos processadores distribuídos.
É fácil incluir um novo servidor e integrá-lo com o restante do sistema ou fazer a atualização do servidor de forma transparente.
Normalmente requer hardware mais barato Desvantagens
A falta de um modelo de referência compartilhada para dados pode significar dificuldade em prever problemas na integração de dados.
Gerenciamento redundante em cada servidor (backup e recuperação).
Não existe um registro central de nomes e serviços - pode ser difícil encontrar quais servidores e serviços estão disponíveis
63
Modelo em camadas Modelo em camadas: organiza um sistema em
camadas, cada uma das quais fornecendo um conjunto de serviços. Com cada camada sendo implementada por meio dos recursos da camada base.
64
Sistema de gerenciamento de versões
65
Modelo em camadas Vantagens
Apóia o desenvolvimento incremental de sistemas.
Arquitetura modificável e portável.
Desvantagens Estruturar um sistema dessa maneira pode ser
difícil. Problemas de desempenho.
66
Arquitetura de Sistemas Distribuídos
Sistema distribuído O processamento de informações é
distribuído em vários computadores ao invés de confinado em uma única máquina.
Bastante comum em qualquer organização Estilos de arquitetura comuns
Arquiteturas de múltiplos processadores Arquiteturas cliente-servidor Arquiteturas de objetos distribuídos Computação interorganizacional
67
Características do sistema distribuído
Compartilhamento de recursos Interoperabilidade
Uso de equipamento e software de fabricantes diferentes.
Concorrência Processamento concorrente para aumentar o
desempenho. Escalabilidade
Capacidade ampliada pela adição de novos recursos. Tolerância a falhas
A capacidade de continuar em operação após a ocorrência de uma falha.
68
Características do sistema distribuído
Complexidade Tipicamente, sistemas distribuídos são mais
complexos que sistemas centralizados. Segurança
Mais suscetível a ataques externos. Gerenciamento
Mais esforço é necessário para o gerenciamento do sistema.
Imprevisibilidade Respostas imprevisíveis dependendo da
organização do sistema e da carga de rede.
69
Arquiteturas de Multiprocessadores
Sistema composto de múltiplos processos que podem (mas não precisam) executar em processadores diferentes.
Distribuição de processo para processador pode ser predeterminada ou pode estar sob o controle de um escalonador.
70
Arquiteturas de Multiprocessadores
71
Arquiteturas cliente-servidor A aplicação é modelada como um conjunto de
serviços que são fornecidos pelos servidores e um conjunto de clientes que usam estes serviços.
Os clientes sabem da existência dos servidores mas os servidores não sabem dos clientes.
s1
s2 s3
s4c1
c2 c3 c4
c5
c6c7 c8
c9
c10
c11c12
Client process
Server process
72
Arquitetura C-S em camadas Camada de apresentação
Está relacionada à apresentação dos resultados de um processamento para os usuário do sistema, e à coleta de entradas do usuário.
Camada de processamento de aplicação Está relacionada ao fornecimento de
funcionalidade específica da aplicação, por exemplo, em um sistema de banco, funções bancárias, tais como abrir conta, fechar conta, etc.
Camada de gerenciamento de dados Está relacionada ao gerenciamento do
banco de dados do sistema.
73
Clientes magros e gordos Modelo de cliente-magro (Thin-client)
Em um modelo cliente-magro, todo o processamento de aplicação e o gerenciamento de dados é realizado no servidor. O cliente é responsável, simplesmentes por executar o software de apresentação.
Modelo de cliente-gordo (Fat-client) Nesse modelo, o servidor é responsável somente
pelo gerenciamento de dados. O software do cliente implementa a lógica da aplicação e as interações com o usuário do sistema.
74
Clientes magros e gordos
75
Arquiteturas de três camadas
Camada de Apresentação Trata da apresentação dos resultados de uma
computação para os usuários do sistema e das formas de entrada de dados do usuário no sistema.
Camada de Aplicação Fornece funcionalidades específicas da
aplicação (ex., abertura e fechamento de conta em um sistema bancário)
Camada de dados Gerenciamento dos sistemas de banco de
dados.
76
Arquiteturas de três camadas
77
Arquitetura de Objetos Distribuídos
Não existe distinção entre clientes e servidores em uma arquitetura de objetos distribuídos.
Cada entidade distribuível é um objeto que fornece serviços para outros objetos e recebe serviços de outros objetos.
Os objetos se comunica através de um sistema de middleware chamado requisitor de objetos.
78
Software bus
o1 o2 o3 o4
o5 o6
S (o1) S (o2) S (o3) S (o4)
S (o5) S (o6)
79
Middleware CORBA Middleware
Software que gerencia e apóia os componentes diferentes de um sistema distribuído. Em essência, ele se situa no meio do sistema.
CORBA Padrão internacional para um localizador de
objetos (Object Request Broker) para gerenciar a comunicação entre objetos distribuídos.
80
Middleware CORBA
81
Arquiteturas orientadas a serviços SOA
Serviços “Uma ação ou desempenho oferecido de um grupo
para um outro. Embora o processo possa estar ligado a um produto
físico, o desempenho é essencialmente intangível e não resulta normalmente em propriedade de algum dos fatores de produção”.
O fornecimento dos serviços é, portanto, independente da aplicação que usa o serviço.
Um web service é uma abordagem padronizada para tornar um componente reusável disponível e acessível através da rede
82
Arquiteturas orientadas a serviços SOA
83
Exemplo Um sistema de informações de um automóvel
fornece aos motoristas informações sobre o clima, condições de tráfego, informações locais, etc. O sistema é ligado ao aparelho de rádio do automóvel que apresenta as informações como um sinal de emissora de rádio específica.
O automóvel é equipado com um receptor GPS para informar sua posição e, baseado nessa posição, o sistema acessa uma gama de serviços de informações. A informação pode ser fornecidas no idioma especificado pelo motorista.
84
85
Referências
PRESSMAN, Roger S. Engenharia de Software. 5. ed. São Paulo: Makron Books, 2006.
SOMMERVILLE, Ian. Engenharia de Software. 8. ed. São Paulo: Pearson, 2007.