Conteúdo. Disciplina: INF Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo

Transcrição

1 Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Disciplina: INF Prof.: Conteúdo 1. Introdução 2. Processo de Software 3. Gerência de Projetos de Software 4. Gerência da Qualidade 5. Especificação e Análise de Requisitos 7. Implementação e Testes 8. Entrega e Manutenção 1

2 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. 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. 2

3 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). 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): If... Then... If... Else... Then... Else... Camada de Domínio do Problema Camada de Interface com o Usuário Camada de Gerência de Dados 3

4 Uma relação importante para um bom Projeto de Software Baixo Acoplamento e Alta Coesão 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 4

5 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 predefinido 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. Documentação de Projeto É apresentada em diferentes níveis de abstração. Documento de Projeto de Sistema 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. 5

6 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. 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: 6

7 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 Projetando a Arquitetura 3. Estabelecer uma arquitetura base, identificando os componentes e relacionamentos entre eles de acordo com os estilos arquitetônicos escolhidos. Combinando partições e camadas 7

8 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. Usando o padrão de Camada de Serviço 8

9 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. 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). 9

10 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) Exemplo Diagrama de classes de análise: 10

11 Exemplo Diagrama de classes de projeto 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: 11

12 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. Exemplo Diagrama parcial do Componente de Interface com o Usuário 12

13 Exemplo Projeto da Interface (as janelas apresentadas no modelo do CIU) 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. 13

14 Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Disciplina: INF Prof.: 14