Disciplina: INF 09289 Engenharia de Software · de projeto da arquitetura de software e podem ser vistos como modelos (templates) para arquiteturas de software concretas. Padrões

1

Universidade Federal do Espírito Santo

Centro Tecnológico

Departamento de Informática

Prof.: Monalessa Perini Barcellos

([email protected])

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


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.


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

If ....Then ....Else ....

Camada de Gerência de

Dados

Camada de Domínio do Problema

Camada de Interface com o Usuário

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


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



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.


Documento de Projeto de Sistema

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.




1. Identificar a plataforma de implementação do sistema (linguagem de programação, banco de dados, mecanismo

de persistência etc).

Exemplo:


7



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




Combinando partições e camadas


3. Estabelecer uma arquitetura base, identificando os componentes e relacionamentos entre eles de

acordo com os estilos arquitetônicos escolhidos.

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

9




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

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:

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:

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

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.

14

Universidade Federal do Espírito Santo

Centro Tecnológico

Departamento de Informática

Prof.: Monalessa Perini Barcellos

([email protected])

Disciplina: INF 09289 – Engenharia de Software

Documents

Disciplina: INF 09289 Engenharia de Software · de projeto da arquitetura de software e podem ser vistos como modelos (templates) para arquiteturas de software concretas. Padrões