Projeto de Sistemas de Software
(PSS)
Prof. Carlos J. P. Lucena
Assunto
• Técnicas de projeto
– Utilizadas para o desenvolvimento de software
– Orientado a objetos
– Promovendo a reutilização de software
© LES/PUC-Rio
Ementa
• Revisão de UML
– Princípios de Modelagem
– Diagrama e Descrição de Casos de Uso
– Diagrama de Classes
– Diagrama de Seqüências
• Introdução à Arquitetura J2EE
• Reuso de Software
– Overview
– Design Patterns
– Frameworks
– Linha de Produtos de Software
© LES/PUC-Rio
Ementa
• Introdução a Agentes
– Conceitos básicos
– Plataforma JADE
• Introdução a Orientação a Aspectos
– Conceitos básicos
– AspectJ (Exemplos)
© LES/PUC-Rio
Avaliação
• Avaliação
– Freqüência e participação do aluno (FP)
– Trabalho Experimental (TE)
• Projetar (utilizando UML) e implementar uma aplicação em
Java
– Trabalho sobre Padrões de Projeto (TPP)
• Apresentar alguns padrões de projeto e implementá-los (em
Java) em exemplos simples
– Trabalho Final (TF)
• Projetar e implementar (em Java) uma Linha de Produto de
Software
• Derivar um produto
• Utilizar padrões de projetos e agentes de software
Nota Final = (0,25 * TE) + (0,15 * TPP) + (0,5 * TF) +- (0.1 * FP)
© LES/PUC-Rio
Avaliação
• Trabalhos
– Trabalho Experimental (TE)
• Preparatório para o trabalho final
– Trabalho Final (TF)
• Acompanhamento semanal dos progressos do trabalho
• Documentação baseada num documento padrão a ser
disponibilizado
• Principais artefatos gerados
– Diagramas UML (Casos de Uso, Classes, Seqüência)
– Descrição dos Casos de Uso
– Código
© LES/PUC-Rio
Equipe
• Prof. Carlos Lucena
– [email protected]
• Instrutores
– Ingrid Nunes
• [email protected]
– Camila Nunes
• [email protected]
– Baldoino Fonseca
• [email protected]
– Manoel Teixeira
• [email protected]
© LES/PUC-Rio
Agenda
Março
09/03
Apresentação do Curso e Visão Geral
16/03
UML (Casos de Uso e Diagrama de Classes)
23/03
UML (Diagrama de Seqüência)
Arquitetura J2EE (Servlet + JSP)
30/03
Design Patterns
© LES/PUC-Rio
Agenda
Abril
06/04
Apresentação do Trabalho de Design Patterns
13/04
Agentes (teoria e exemplos)
27/04
Frameworks OO
Dúvidas do sobre o Trabalho Final
© LES/PUC-Rio
Agenda
Maio
04/05
Linhas de Produto Software
11/05
Trabalho Final: Apresentação inicial
Entrega do Trabalho Experimental
18/05
Programação Orientada a Aspectos
25/05
Trabalho Final: Apresentação do Problema (Diagrama de
Features)
© LES/PUC-Rio
Agenda
Junho
01/06
Trabalho Final: Apresentação (Diagramas de Casos de Uso e
Diagramas de Classes)
08/06
Trabalho Final: Apresentação (Diagramas de Seqüência)
15/06
Trabalho Final: Apresentação (Diagr. Classe e Seq.
Refinados + Patterns)
22/06
Trabalho Final: Apresentação (Diagr. Classe e Seq.
Refinados + Demo)
29/06
Trabalho Final: Apresentação Final (Documentação + Demo
Final)
06/07
Trabalho Final: Entrega do Documento
13/07 – Divulgação das Notas Finais
© LES/PUC-Rio
Apoio Educacional
• Recursos
– Aulas
• Segunda-feira, das 13h às 16h
• Fundação Padre Leonel Franca - 13o Andar
– Atendimento
• Camila Nunes ([email protected])
• Baldoino Fonseca ([email protected])
• Ingrid Nunes ([email protected])
• Manoel Teixeira ([email protected])
– Wiki
• http://web.teccomm.les.inf.pucrio.br/index.php/Projeto_de_Sistemas_de_Software
– Grupo
• http://br.groups.yahoo.com/group/pss-puc-rio-20091
• Enviar mensagem: [email protected]
• Entrar no grupo: [email protected]
© LES/PUC-Rio
Apoio Educacional
• Horário de Atendimento
– 2as feiras - das 10h às 12h
• Baldoino Fonseca
– 2as feiras - das 16h às 18h
• Ingrid Nunes
– 3as feiras - das 14h às 16h
• Manoel Teixeira
– 6as feiras - das 10h às 12h
• Camila Nunes
© LES/PUC-Rio
Projeto de Sistemas de Software
(PSS)
Visão Geral
Reuso de Software
ES baseada em Reuso
• Reuso de Sistemas
– Uma aplicação pode ser reutilizada incorporando-se à
outros sistemas sem necessidade de mudança ou com
algumas configurações
• Reuso de Componentes
– Componentes de software que implementam um conjunto
de funções podem ser reutilizados
• Reuso de Funções
– Componentes de software que implementam uma única
função podem ser reutilizados
© LES/PUC-Rio
Benefícios do Reuso
• Maior confiabilidade
– Componentes já utilizados e testados em outros sistemas
são mais confiáveis que novos componentes
• Redução dos riscos de processo
– Menos incerteza nos custos de reuso comparado aos custos de
desenvolvimento
• Uso efetivo de especialistas
– O especialista desenvolve software reutilizável encapsulando seu
conhecimento, ao invés de desenvolver as mesmas funcionalidades
repetidas vezes em diferentes projetos
• Uso efetivo de padrões
– O uso de padrões organizacionais agiliza o desenvolvimento pois
estabelece uma base comum de comunicação e garante a consistência
• Desenvolvimento acelerado
– Evitando o desenvolvimento de produtos “originais” é possível acelerar a
produção e a validação
© LES/PUC-Rio
Problema do Reuso
• Aumento nos custos de manutenção
– Dificuldade de adaptar componentes sem o código fonte
• Dificuldade em encontrar e adaptar componentes
reutilizáveis
• Síndrome do “não-foi-inventado-aqui”
– Falta de confiança no componente
– Desenvolvedor prefere reimplementar
pois acredita poder aprimorá-lo
© LES/PUC-Rio
Reuso de Projeto e Implementação
• Neste curso, serão abordados algumas técnicas
que propiciam o reuso de projeto e implementação
em sistemas OO
– Padrões de Projeto (Design Patterns)
– Frameworks
– Linhas de Produto
© LES/PUC-Rio
Padrões de Projeto
(Design Patterns)
Definição: Padrão
“Cada padrão descreve um problema que ocorre
repetidas vezes em nosso ambiente, e então
descreve o núcleo da sua solução para aquele
problema, de tal maneira que seja possível usar
essa solução milhões de vezes sem nunca fazê-la
da mesma forma duas vezes.”
Christopher Alexander sobre padrões em arquitetura de
construções
© LES/PUC-Rio
Definição: Padrão de Projeto
“Os padrões de projeto são descrições de objetos
que se comunicam e classes que são customizadas
para resolver um problema de projeto genérico em
um contexto específico.”
Gamma, Helm, Vlissides & Johnson, sobre padrões de projeto em
software
© LES/PUC-Rio
Padrões de Projeto
• Formas de reutilizar conhecimento abstrato
sobre problemas e soluções
• Descrições de problemas e essências de soluções
• Aplicáveis em classes de problemas bem
conhecidos
• Soluções que funcionam, tornando-se “receitas”
para situações similares
• OBS: Desde que estas soluções tenham sido
projetadas com flexibilidade
© LES/PUC-Rio
Bibliografia
• Bibliografia
– Design Patterns: Elements
of Reusable ObjectOriented Software
• Publicado em 1994
• Autores:
– Erich Gamma
– John Vlissides
– Ralph Jonhson
– Richard Helm
• conhecidos como:
– “The Gang of Four” (GoF)
• Contém 23 padrões de
projeto
© LES/PUC-Rio
Benefícios
• Aprendizagem com a experiência dos outros
– Identificação de problemas comuns de projeto de software
– Utilização de soluções testadas e bem documentadas
– Ajuda um novato a agir mais como um experiente
• Aumento da produtividade
• Melhoria na qualidade do projeto OO
– Normalmente utilizam boas práticas de OO
– Utilizam eficientemente polimorfismo, herança e composição
• Vocabulário comum
– Uso de soluções conhecidas facilita a comunicação e
documentação
• Ajuda na conversão de um modelo de análise em um modelo
de implementação
© LES/PUC-Rio
Exemplo: Adapter Pattern
• Você já precisou ligar seu laptop na tomada num
país estrangeiro?
© LES/PUC-Rio
Exemplo: Adapter Pattern
• Existem diversos adaptadores
© LES/PUC-Rio
Exemplo: Adapter Pattern
O plug do laptop
espera outra
interface
A tomada oferece
uma interface
O adaptador
converte uma
interface na outra
© LES/PUC-Rio
Exemplo: Adapter Pattern
• Suponha que você tem um sistema que usa o
componente A
Interfaces
compatíveis
Componente
A
Seu
sistema
© LES/PUC-Rio
Exemplo: Adapter Pattern
• Porém o fornecedor do componente A faliu…
• Você precisa utilizar o componente de outro
fornecedor
Componente
A
Seu
sistema
© LES/PUC-Rio
Exemplo: Adapter Pattern
• Porém, o fornecedor do componente B oferece
uma interface incompatível com o seu sistema
Interfaces
incompatíveis
Componente
B
Seu
sistema
© LES/PUC-Rio
Exemplo: Adapter Pattern
• Para não correr riscos, você cria um adaptador
Interfaces
compatíveis
Seu
sistema
Sem alteração
de código
Adaptador
Código novo
© LES/PUC-Rio
Interfaces
compatíveis
Componente
B
Sem alteração
de código
Exemplo: Adapter Pattern
• Problema
– Como adaptar a interface de dois componentes?
• Solução
– Adapter Pattern
• “Converte a interface para outra interface que o
cliente espera encontrar. O adaptador permite que
componentes com interfaces incompatíveis
trabalhem juntos”
© LES/PUC-Rio
Frameworks
Frameworks de Aplicação
• Framework de aplicação
– Projeto constituído de uma coleção de classes concretas e
abstratas, e de interfaces entre elas
• Instância do framework
– Implementada pela adição de detalhes específicos e pela
instanciação das classes abstratas
• Frameworks
– Entidades “relativamente” grandes que podem ser
reutilizadas
© LES/PUC-Rio
Estendendo Frameworks
• Frameworks
– Genéricos
– Estendidos para criar uma aplicação ou sub-sistema
específico
• Estender um framework envolve
– Adicionar classes concretas que herdam operações
das classes abstratas do framework
• Problemas:
– complexidade
– tempo necessário para usá-los efetivamente
© LES/PUC-Rio
Estrutura de um framework
• Um framework separa o que é fixo (frozen-spots) do que é
variável (hot-spots)
Specific
Application Code
#1
© LES/PUC-Rio
Exemplo framework
• Framework de Análise e Persistência de dados
#2
Anal.
Estatística
#1
MySQL
Hot-Spot #1
Tipo de persistência
Hot-Spot #2
Algoritmo de Análise
Implementação do
Hot-Spot #1
Implementação do
Hot-Spot #2
© LES/PUC-Rio
Linha de Produto
Linhas de Produto de Software
• Conjunto de sistemas
– Compartilham características comuns e gerenciáveis que
satisfazem às necessidades de um segmento particular do
mercado.
• Produtos derivados
– chamados de família de produtos
• Arquitetura SPL
– Conjunto de features comuns e variáveis de uma família
de produtos
© LES/PUC-Rio
Linhas de Produto de Software
• A maioria dos sistemas não são novos
• Construir pontos de variação usando artefatos da
linha de produto
– Arquiteturas Comuns
– Componentes
Construídos com
Pontos de Variação
© LES/PUC-Rio
Linhas de Produto de Software
Domínio de Aplicação /
Estratégia de Mercado
pertencem
compartilham
Arquitetura
Produtos
construídos por
Componentes
© LES/PUC-Rio
Linhas de Produto de Software
© LES/PUC-Rio
Exemplo de LP
• Exemplo: Indústria Automobilística
• Carro
– Caixa de Marcha
Pontos de Variação
• Automática
• Manual
Variantes
– Motor
• Diesel
• Gasolina
– Tipo de Motor
• 1.0
• 1.6
– ...
© LES/PUC-Rio
Agentes de Software
Cenário Atual
• Com os avanços do desenvolvimento de
aplicações distribuídas na Internet, a
introdução de componentes de software com
algum tipo de auto-controle está se tornando usual
• Os sistemas de software deverão estar
– Em todo o lugar
– Sempre conectados (disponíveis)
– Sempre ativos para executar requisições de usuários
© LES/PUC-Rio
Evolução dos Paradigmas de ES
• Linguagens Assembler
• Abstração Funcional
• Programação Estruturada
• Orientação a Objetos
Tempo
• Componentes
• ...
• Agentes de Software
© LES/PUC-Rio
O que são Agentes?
• Inteligência Artificial
– Um agente é pró-ativo, inteligente, e deve ser altamente
interativo (P2P) em vez de participar de uma arquitetura
cliente-servidor
• Engenharia de Software
– Um agente é um componente de software com processos
internos de execução (threads), tanto pró-ativo quanto
reativo, e que pode participar de protocolos de interação
complexos e com estado
© LES/PUC-Rio
Exemplos de Agentes
• Buscam, negociam e montam pacotes de viagens
• Representam usuários em um sistema de leilão
(negociam produtos)
• Buscam informações de interesse de usuários na
Internet
• Realizam monitoramento de estado e enviam
alertas
© LES/PUC-Rio
Projeto de Sistemas de Software
(PSS)
Exemplo de Trabalho Final
ExpertCommittee
• Análise do Domínio
– Sistema para gerenciamento de conferências
• Suportam a maioria das tarefas administrativas de
conferencias
• Gerenciamento mais fácies destes eventos mais fáceis
• Redução o tempo gasto
– Exemplos
• JEMS (https://submissoes.sbc.org.br/)
• ConfMaster (http://www.confmaster.net/)
• ConfTool (http://www.conftool.net/)
• EasyChair (http://www.easychair.org/)
© LES/PUC-Rio
ExpertCommittee
© LES/PUC-Rio
EC – Feature Model
© LES/PUC-Rio
EC – Use Case Diagram
© LES/PUC-Rio
EC – Class Diagram (Core)
© LES/PUC-Rio
EC – Class Diagram (Agentes)
© LES/PUC-Rio
EC - Arquitetura
© LES/PUC-Rio