disciplina: inf 09289 engenharia de software · de projeto da arquitetura de software e podem ser...
Post on 16-Dec-2018
217 Views
Preview:
TRANSCRIPT
1
Universidade Federal do Espírito Santo
Centro Tecnológico
Departamento de Informática
Prof.: Monalessa Perini Barcellos
(monalessa@inf.ufes.br)
Disciplina: INF 09289 – Engenharia de Software
Conteúdo
1. Introdução
2. Processo de Software
3. Especificação e Análise de Requisitos
4. Projeto de Sistema
5. Implementação e Testes
6. Entrega e Manutenção
7. Gerência da Qualidade
8. Gerência de Projetos de Software
9. Tópicos Avançados em Engenharia de SoftwareEngenharia de Software Monalessa Perini Barcellos
2
4. Projeto de Sistemas
A etapa de Projeto tem início assim que os requisitos do software tiverem sido
modelados e especificados (pelo menos parcialmente ).
É a última atividade de modelagem.
É a primeira atividade que leva em conta aspectos tecnológicos.
Engenharia de Software Monalessa Perini Barcellos
4. Projeto de Sistemas
Independente do paradigma adotado, a etapa de Projeto inclui definir:
Projeto da Arquitetura do Software: visa definir os elementos estruturais
do software e seus relacionamentos.
Projeto dos Elementos da Arquitetura: visa projetar em um maior nível de
detalhes cada um dos elementos estruturais definidos na arquitetura.
Projeto de Interfaces: tem por objetivo descrever como deverá se dar a
comunicação entre os elementos da arquitetura (interfaces internas), a
comunicação do sistema em desenvolvimento com outros sistemas
(interfaces externas) e com as pessoas que vão utilizá-lo (interface com o
usuário).
Projeto Detalhado: visa refinar e detalhar a descrição procedimental e das
estruturas de dados dos elementos mais básicos da arquitetura do software.
Engenharia de Software Monalessa Perini Barcellos
3
4. Projeto de Sistemas
Considerando o paradigma orientado a objetos, fazem parte da arquitetura de um
sistema:
Lógica de Domínio: é o elemento da arquitetura que trata de toda a lógica do
sistema, englobando tanto aspectos estruturais (classes de domínio derivadas dos
modelos conceituais estruturais da fase de análise), quanto comportamentais
(classes de processo que tratam das funcionalidades descritas pelos casos de uso).
Interface com o Usuário: é o elemento da arquitetura que trata da interação
humano-computador. Envolve tanto as interfaces propriamente ditas (objetos
gráficos responsáveis por receber dados e comandos do usuário e apresentar
resultados) quanto o controle da interação, abrindo e fechando janelas, habilitando
ou desabilitando botões etc.
Persistência: é o elemento da arquitetura responsável pelo armazenamento e
recuperação de dados em memória secundária (classes que representam e isolam
os depósitos de dados do restante do sistema).
Engenharia de Software Monalessa Perini Barcellos
4. Projeto de Sistemas
Mas… o que é a arquitetura de software?
De modo geral, pode-se dizer que a arquitetura do software descreve os
elementos que compõem o software, seus relacionamentos e interfaces.
Exemplo (camadas típicas em sistemas de informação):
Engenharia de Software Monalessa Perini Barcellos
If ....Then ....Else ....
If ....Then ....Else ....
Camada de Gerência de
Dados
Camada de Domínio do Problema
Camada de Interface com o Usuário
4
4. Projeto de Sistemas
Uma relação importante para um bom Projeto de Software
Baixo Acoplamento e Alta Coesão
Engenharia de Software Monalessa Perini Barcellos
4. Projeto de Sistemas
Padrões (Patterns)
• Um padrão é uma solução testada e aprovada para um problema geral.
• Um padrão vem com diretrizes sobre quando usá-lo, bem como vantagens e
desvantagens de seu uso.
• Um padrão já foi cuidadosamente considerado por outras pessoas e aplicado
diversas vezes na solução de problemas anteriores de mesma natureza.
• Um padrão normalmente tem o formato de um par nomeado
problema/solução, que pode ser utilizado em novos contextos, com orientações
sobre com utilizá-lo nessas novas situações
Engenharia de Software Monalessa Perini Barcellos
5
4. Projeto de Sistemas
Considerando padrões relacionados à fase de projeto, há três grandes categorias:
Padrões Arquitetônicos: definem uma estrutura global do sistema. Um padrão arquitetônico
indica um conjunto pré-definido de subsistemas, especifica as suas responsabilidades e inclui
regras e orientações para estabelecer os relacionamentos entre eles. São aplicados na atividade
de projeto da arquitetura de software e podem ser vistos como modelos (templates) para
arquiteturas de software concretas.
Padrões de Projeto (Design Patterns): proveem um esquema para refinar subsistemas ou
componentes de sistema de software, ou os relacionamentos entre eles. Atendem a uma
situação específica de projeto, mostrando classes e relacionamentos, seus papéis e suas
colaborações e também a distribuição de responsabilidades.
Idiomas: representam o nível mais baixo de padrões, endereçando aspectos tanto de projeto
quanto de implementação. Um idioma é um padrão de baixo nível, específico de uma
linguagem de programação, descrevendo como implementar aspectos particulares de
componentes ou os relacionamentos entre eles usando as características de uma dada
linguagem.
Engenharia de Software Monalessa Perini Barcellos
4. Projeto de Sistemas
Documentação de Projeto
• É apresentada em diferentes níveis de abstração.
• Inclui:
Plataforma de Implementação: informa as tecnologias utilizadas para implementar o
sistema (plataforma de implementação) e para operar o sistema (plataforma de operação).
Arquitetura do Software: descreve a arquitetura geral do software, apresentando seus
componentes e as relações entre eles.
Projeto Detalhado: descreve em detalhes cada um dos componentes da arquitetura. São
apresentados diagramas de classes (e outros) detalhados para cada componente.
Nota: nesta abordagem de documentação, a interface é vista como um componente da arquitetura, por isso não
aparece em uma seção específica.
Engenharia de Software Monalessa Perini Barcellos
Documento de Projeto de Sistema
6
4. Projeto de Sistemas
Projetando a Arquitetura
1. Identificar a plataforma de implementação do sistema (linguagem de programação, banco
de dados, mecanismo de persistência etc).
2. Decompor o sistema em subsistemas (isso pode já ter sido feito na análise) e escolher um
estilo arquitetônico (ou uma combinação) para organizar a estrutura geral do sistema.
3. Estabelecer uma arquitetura base, identificando os componentes e relacionamentos entre
eles de acordo com os estilos arquitetônicos escolhidos.
4. Alocar requisitos funcionais (casos de uso) e não funcionais aos componentes da
arquitetura.
5. Avaliar a arquitetura, procurando identificar se ela acomoda os requisitos identificados.
6. Detalhar a arquitetura dos componentes.
Engenharia de Software Monalessa Perini Barcellos
4. Projeto de Sistemas
Projetando a Arquitetura
1. Identificar a plataforma de implementação do sistema (linguagem de programação, banco de dados, mecanismo
de persistência etc).
Exemplo:
Engenharia de Software Monalessa Perini Barcellos
7
4. Projeto de Sistemas
Projetando a Arquitetura
2. Decompor o sistema em subsistemas (isso pode já ter sido feito na análise) e escolher um estilo arquitetônico
(ou uma combinação) para organizar a estrutura geral do sistema.
Exemplo: Um estilo arquitetônico que combina PARTIÇÕES e CAMADAS
Partições: definidas de acordo com o domínio do problema (= subsistemas).
Camadas: arquitetura típica dos sistemas de informação.
Camada de Domínio do Problema
Camada de Interface com o Usuário
Camada de Gerência de Dados
Engenharia de Software Monalessa Perini Barcellos
4. Projeto de Sistemas
Engenharia de Software Monalessa Perini Barcellos
Combinando partições e camadas
Projetando a Arquitetura
3. Estabelecer uma arquitetura base, identificando os componentes e relacionamentos entre eles de
acordo com os estilos arquitetônicos escolhidos.
8
4. Projeto de Sistemas
O uso de patterns pode ajudar a definir a arquitetura do software.
Exemplo:
Padrão Camada de Serviço.
Divide a lógica de negócio em dois tipos de lógica, com um componente para cada tipo:
• Lógica de domínio do problema = Componente de Domínio do Problema: classes
previamente identificadas na fase de análise.
• Lógica da aplicação = Componente de Gerência de Tarefas: funcionalidades
descritas pelos casos de uso.
Engenharia de Software Monalessa Perini Barcellos
4. Projeto de Sistemas
Engenharia de Software Monalessa Perini Barcellos
Usando o padrão de Camada de Serviço
9
4. Projeto de Sistemas
Engenharia de Software Monalessa Perini Barcellos
Projetando a Arquitetura
6. Detalhar a arquitetura dos componentes.
Componente Domínio do Problema (CDP)
• O modelo de classes do componente Domínio do Problema
é a visão de projeto do modelo de classes gerado na etapa de análise.
• Deve-se fazer uma cópia do modelo de classes gerado na análise e realizar algumas
mudanças.
4. Projeto de Sistemas
Engenharia de Software Monalessa Perini Barcellos
Mudanças no modelo de classes da fase de análise para a fase de projeto:
1. Incluir informações dos tipos de atributos, caso isso não tenha sido feito na análise.
2. Incluir a visibilidade dos atributos (tipicamente, atributos só devem ser acessados pelas
suas classes ou subclasses).
3. Incluir a navegabilidade nas associações (identifica que objeto faz referência a outro
objeto ou a uma lista de objetos).
4. Incluir métodos nas classes (métodos básicos – get, set, delete e update – não precisam
aparecer. Somente métodos que não podem ser deduzidos devem aparecer na classe).
5. Eliminar classes associativas (devem ser substituídas por classes normais).
10
4. Projeto de Sistemas
Engenharia de Software Monalessa Perini Barcellos
Além disso…
6. Verificar a possibilidade de reutilizar classes de sistemas já existentes.
7. Verificar as generalizações/especializações (podem ter surgido novas ou podem
necessitar de mudanças devido à linguagem de programação e/ou banco de dados).
8. Ajustar o modelo para cobrir aspectos de:
• Desempenho (criação de atributos ou associações redundantes para agilizar as
computações etc).
• Interface (criação de tipos enumerados etc)
• Segurança (inclusão de classes para tratar de autenticação etc)
4. Projeto de Sistemas
Engenharia de Software Monalessa Perini Barcellos
Exemplo
Diagrama de classes de análise:
11
4. Projeto de Sistemas
Engenharia de Software Monalessa Perini Barcellos
Exemplo
Diagrama de classes de projeto
4. Projeto de Sistemas
Engenharia de Software Monalessa Perini Barcellos
Componente de Gerência de Tarefas (CGT)
• Contém as classes que irão gerenciar as tarefas do software,
ou seja, suas funcionalidades.
• Seu projeto está fortemente relacionado aos casos de uso.
• Uma abordagem comum, é definir uma classe de aplicação
para cada caso de uso, no entanto, casos de uso relacionados
podem ser agrupados em uma única classe de aplicação.
Exemplo:
12
4. Projeto de Sistemas
Engenharia de Software Monalessa Perini Barcellos
Componente de Interface com o Usuário (CIU)
Envolve dois tipos de funcionalidades:
Visão: objetos gráficos usados na interação com o usuário.
Controle de Interação: controle da lógica da interface,
envolvendo a ativação dos objetos gráficos (abrir ou fechar uma
janela, habilitar ou desabilitar um item de menu etc.) e o disparo de ações.
Pattern: Modelo-Visão-Controlador (MVC)
Modelo: objetos da camada lógica de negócio.
Visão: entrada de dados e exibição de informações.
Controlador: pega a entrada do usuário, envia uma requisição para a camada de lógica
de negócio, recebe sua resposta e solicita que a visão se atualize conforme apropriado.
4. Projeto de Sistemas
Engenharia de Software Monalessa Perini Barcellos
Exemplo
Diagrama parcial do Componente de Interface com o Usuário
13
4. Projeto de Sistemas
Engenharia de Software Monalessa Perini Barcellos
Exemplo
Projeto da Interface (as janelas apresentadas no modelo do CIU)
4. Projeto de Sistemas
Engenharia de Software Monalessa Perini Barcellos
Componente de Gerência de Dados (CGD)
• Responsável pela persistência dos dados em arquivos ou bancos
de dados.
• Sistemas tipicamente utilizam um SGBD (Sistema Gerenciador
de Banco de Dados)
• Quando são usados SGBDs relacionais, é necessário um mapeamento entre as
estruturas de dados dos modelos orientado a objetos e relacional, de modo que
objetos possam ser armazenados em tabelas.
• Existem frameworks de persistência de objetos em bancos de dados relacionais (ou
frameworks de mapeamento objeto-relacional). Exemplo: Hibernate.
• Padrão DAO - Data Access Object : o CGD serve como uma camada intermediária
separando objetos do domínio de objetos de gerência de dados. Via conexões de
mensagem, o CGD lê e escreve dados, estabelecendo uma comunicação entre a base
de dados e os objetos do sistema. Qualquer código SQL está confinado nessas classes,
de modo que não há código desse tipo em outras classes da arquitetura do software.
top related