Projecto de Software

Mário Sitoe
 Sumário
Projecto de Software
➢ Modularização e Independência Funcional
➢ Refinamento, Projecto Conceptual
➢ Projecto de Interface
➢ Projecto de BD
➢ Projecto de Arquitectura
➢ Projecto Detalhado
➢ Padrões de Arquitectura
➢ Documento de Projecto

Mário Sitoe
 Projecto de arquitectura

➢ É o processo de projecto de Software que visa identificar os subsistemas que

compõem um sistema e o framework para controle e comunicação do subsistema.
➢ Resulta na descrição da arquitectura do software.
 Projecto de arquitectura

➢ Visa identificar os principais componentes do sistema e suas comunicações

➢ Representa a ligação entre a especificação e os processos do projecto de software.
➢ Geralmente é realizado em paralelo com algumas actividades de especificação.
Projecto de arquitectura
Exemplo: Sistema de Controle Robotizado de Empacotamento
Abstração sobre arquitectura

➢ EM pequena escala se preocupa com a arquitectura dos programas

individuais: como o programa é decomposto em componentes.
➢ Em grande escala se preocupa com a arquitectura de sistemas corporativos
que incluem outros sistemas, programas e componentes do programa:
sistemas que estão distribuidos em diferentes computadores, que podem ser
possuídos e geridos por diferentes empresas.
Vantagens da arquitectura explícita

Comunicação de stakeholders
➢ A arquitectura pode ser usada como um foco de discussão pelos stakeholders
do sistema.

Análise de sistemas
➢ Possibilita maior compreensão do sistema e da implementação dos
requisitos do sistema.

Reeúso em larga escala

➢ A arquitectura pode ser reusável em uma variedade de sistemas. Podem ser
desenvolvidas arquiteturas de linhas de produtos.
Padrões de arquitectura

Embora cada sistema seja único, é comum que sistemas do mesmo domínio
tenham arquitecturas similares.
➢ Um padrão de arquitetura é uma descrição estilizada das boas práticas de
projecto, que tem sido experimentadas e testadas em diferentes ambientes.

Padrões arquiteturais definem

➢ Um conjunto de sub-sistemas
➢ As responsabilidades de cada sub-sistema
➢ Regras de relacionamentos entre os subsistemas
Padrões de arquitectura

Padrões arquitectuais representam os padrões mais abstractos

➢ Padrões de projecto (modelagem)
➢ Linguagem de programação

Padrões arquitectuais não representam completamente a arquitectura do

sistema
➢ Padrões são templates que devem ser refinados

Exemplos de refinamentos
➢ Incluir outros componentes e novos relacionamentos
➢ Definir padrões de projecto e idiomas em fases subsequentes
Padrões de arquitectura
 Arquitectura em camadas
➢ Usada para modelar a interface dos subsistemas.
➢ Organiza o sistema em um conjunto de camadas: Cada camada oferece um conjunto
de serviços.

Uma camada somente

➢ Solicita serviços da camada inferior
➢ Fornece serviços para a camada superior

Apoia o desenvolvimento incremental de subsistemas em diferentes camadas.

Quando uma camada na interface muda, apenas a camada adjacente é afetada.
 Arquitectura em camadas

➢ Exemplo: modelo em camadas para um sistema de comunicação: Modelo OSI

 Arquitectura em camadas

Vantagens Desvantagens
➢ Favorece o modelo de desenvolvimento ➢ Estruturar o sistema em camadas não é trivial
incremental ➢ Muitas camadas podem comprometer o
➢ As camadas podem ser facilmente substituídas desempenho do sistema
por equivalentes. ➢ A requisição tem que trafegar pelas várias
➢ Mudanças em uma camada teoricamente só camadas até ser atendida
impacta a camada superior
➢ Camadas superiores podem ser independentes
de plataforma/hardware
Arquitectura em camadas
Exemplo: Sistema de compartilhamento de documentos com direitos autorais, em
bibliotecas diferentes.
Arquitectura de repositório (blackboard)

Subsistemas devem trocar dados. O que pode ser feito de duas maneiras:
➢ Dados compartilhados são guardados em um banco de dados
repositório e podem ser acessados por todos os subsistemas;
➢ Cada subsistema mantém seu próprio banco de dados e dados
explicitamente para outros subsistemas.

❑ Quando grandes quantidades de dados devem ser compartilhadas, é mais

comum o uso do modelo de repositório compartilhado pois esse é um eficiente
mecanismo de compartilhamento de dados.
Arquitectura de repositório (blackboard)
Arquitectura de repositório (blackboard)
Vantagens
➢ Maneira eficiente de compartilhar dados
➢ Backup é centralizado (mais fácil)
➢ Formas de proteção dos dados podem ser
implementadas
➢ Os subsistemas que gravam dados não
necessitam saber quem os usa
➢ Fácil integrar novos subsistemas
Desvantagens
➢ Os subsistemas devem entender o formato dos
dados gravados
➢ Manter e evoluir grandes volumes de dados pode
ser difícil / caro
➢ Subsistemas diferentes podem ter requisitos
diferentes
➢ Mais segurança ou maior disponibilidade
➢ Dificuldade para distribuir os dados
➢ Dados redundantes ou inconsistentes
Arquitectura de repositório (blackboard)

Exemplo: Arquitectura de um IDE

 Arquitectura de Dutos e Filtros

Transformações funcionais processam suas entradas para produzir saídas.

Dutos: componentes que conduzem ou distribuem os dados

Filtros: componentes que transformam os dados

➢ Os dados de entrada se movem pelos dutos

➢ Os dados são transformados pelos filtros até serem convertidos em dados de saída
➢ As transformações podem ocorrem em sequência ou em paralelo

Pode ser referido como um modelo de dutos e filtros (como no shell do UNIX).
Arquitectura de Dutos e Filtros

Exemplo: Sistema de gerenciamento de pagamento

Entradas: Facturas e Pagamentos
Saídas: Receibos e lembretes
 Arquitectura de Dutos e Filtros

Vantagens Desvantagens
➢ O módulo de transformação (filtro) é bem ➢ O formato dos dados trafegados devem ser
modular acordados entre os módulos.
➢ Facilmente reusável e substituível ➢ Pode haver um overhead causado pela
➢ O estilo de workflow é aderente a muitos padronização dos dados
processos de negócios ➢ Incompatibilidade no formato dos dados pode
➢ É simples evoluir o sistema pela adição de filtros dificultar o reuso de filtros
➢ Se aplica tanto a sistemas sequênciais quanto a
sistemas concorrentes
Arquitectura Cliente – Servidor

Requer uma estrutura de rede para clientes acessarem os serviços.

Um conjunto de servidores autônomos que prestam serviços específicos, tais

como impressão, gerenciamento de dados, etc.
➢ Clientes sabem quais os serviços e servidores estão disponíveis
➢ Servidores podem não sabem quem são os clientes.

➢ Essencialmente, é usado o protocolo request-response

➢ É usado quando os dados que estão em banco de dados compartilhado
precisam ser acessados a partir de vários locais.
Arquitectura Cliente – Servidor

Exemplo: biblioteca de filmes e jogos

 Arquitectura Cliente – Servidor

Vantagens Desvantagens
➢ Distribuição fácil e directa de dados ➢ Não prevê modelo de dados compartilhado
➢ Uso efectivo dos recursos ➢ Subsistemas usam diferentes organizações de
➢ Fácil alocação de novos servidores ou dados
actulização dos existententes ➢ Pode haver redundância de serviços em
diferentes servidores
Padrão Modelo-Visão-Controlador (MVC)

➢ Separa a apresentação e a interação dos dados do sistema.

➢ Ideal em sistemas onde há várias formas de se visualizar e interagir com dados.
Tambmém quando não se conhece os futuros requisitos de interação e
apresentação dos dados

Largamente utilizado em aplicações interativas Web. Organiza o sistema em três

componentes
➢ Modelo: contém as funcionalidades e dados principais
➢ Visão: responsável por apresentar os dados ao usuário
➢ Controlador: trata os eventos de entrada
Padrão Modelo-Visão-Controlador (MVC)

Exemplo: Arquitectura Web com MVC

Padrão Modelo-Visão-Controlador (MVC)

Vantagens
Desvantagens
➢ Permite que os dados sejam alterados de forma
➢ Complexidade excessiva quando o modelo de
independente de sua representação (e vice
dados e de interações é muito simples
versa)
➢ A estrutura do padrão pode impor código
➢ Apoia a apresentação dos mesmos dados de
adicional desnecessário
maneiras diferentes
➢ Facilita a distribuição do componente de visão
➢ Os dados são mantidos centralizados e
protegidos.
Diagramas de classe
Diagramas de classe

O diagrama de classes serve de apoio para o desenvolvimento de outros

diagramas, pois:
➢ Estabelece como as classes funcionam e se relacionam;
➢ Permite visualizar as classes que compõem o sistema.
Diagramas de classe

As classes são representadas graficamente por retângulos incluindo seu nome,

os atributos e métodos.

Os atributos de uma classe são a identificação de cada objecto de uma classe. Além do
nome o atributo deve ser o tipo de dado que será armazenado.
Diagramas de classe

Os métodos são as acções (comportamentos) que serão executadas sobre os

atributos das classes. Os métodos são nomeados para indicar algum resultado.
Diagramas de classe

Tipos de Visibilidade
➢ Pública (+)
O atributo ou método pode ser usado por qualquer classe
➢ Protegida (#)
Somente a classe ou subclasses terão acesso
➢ Privada (-)
Somente a classe terá acesso
Relacionamento entre classes

Um relacionamento entre classe possuem:

• Nome;
• Sentido de leitura;
• Navegabilidade;
• Multiplicidade;
• Tipo;
• Papéis.
Multiplicidade
Neste argumento deve ser descrito qual é o valor do relacionamento entre duas
classes, quando esse valor for omitido, o valor padrão se torna o número 1.
MULTIPLICIDADE DESCRIÇÃO

0...1 No máximo um.

1...1 Um e somente um.

0...* Muitos

1...* Um ou muitos

3...5 Valores específicos. De três até cinco.

Multiplicidade

Dentre os principais tipos de relacionamentos entre classes, é possível destacar:

▪ Associação;
▪ Agregação / Composição;
▪ Herança;
▪ Dependência.
Associação
Associação

▪ Um estudante pode participar de nenhuma ou até oito disciplinas

▪ Um estudante compete por no máximo 1 equipe de futebol
▪ Uma equipe de futebol tem de 1 até 22 jogadores
▪ Uma disciplina pode ter no um ou mais alunos.
Agregação

É um tipo especial de associação. Esse relacionamento demonstra que um objecto

precisa ser complementado por um objecto de outra classe.
 GARANTE O TEU FUTURO
COM UMA FORMAÇÃO SÓLIDA