Projeto de Sistemas de Software (PSS) Prof. Carlos J. P. Lucena

Projeto de Sistemas de Software (PSS)

Prof. Carlos J. P. Lucena

© LES/PUC-Rio

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]

© LES/PUC-Rio

Agenda

Agosto11/08 Apresentação do Curso e Visão Geral

18/08 UML (Casos de Uso e Diagrama de Classes)

25/08 UML (Diagrama de Seqüência)

Arquitetura J2EE (Servlet + JSP)

© LES/PUC-Rio

Agenda

Setembro01/09 Design Patterns

08/09 Apresentação do Trabalho de Design Patterns

15/09 Agentes (teoria e exemplos)

22/09 Frameworks OO

Dúvidas do sobre o Trabalho Final

29/09 Linhas de Produto Software

© LES/PUC-Rio

Agenda

Outubro06/10 Trabalho Final: Apresentação inicial

Entrega do Trabalho Experimental

13/10 Programação Orientada a Aspectos

20/10 Trabalho Final: Apresentação do Problema (Diagrama de Features)

27/10 Trabalho Final: Apresentação (Diagramas de Casos de Uso e Diagramas de Classes)

© LES/PUC-Rio

Agenda

Novembro03/11 Trabalho Final: Apresentação (Diagramas de Seqüência)

10/11 Trabalho Final: Apresentação (Diagr. Classe e Seq. Refinados + Patterns)

17/11 Trabalho Final: Apresentação (Diagr. Classe e Seq. Refinados + Demo)

24/11 Trabalho Final: Apresentação Final (Documentação + Demo Final)

01/12 Trabalho Final: Entrega do Documento

08/12 – 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• Ingrid Nunes ([email protected])• Camila Nunes ([email protected])

– Wiki• http://web.teccomm.les.inf.puc-rio.br/index.php/Projeto_de_Si

stemas_de_Software

– Grupo• Página do Grupo

– http://br.groups.yahoo.com/group/pss-puc-rio-20082

• Enviar mensagem: [email protected]• Entrar no grupo: pss-puc-rio-20082-

[email protected]

© LES/PUC-Rio

Apoio Educacional

• Horário de Atendimento– 2as feiras - das 16h às 18h

• Ingrid Nunes

– 6as feiras - das 10h às 12h

• Camila Nunes


Visão Geral

Reuso de Software

© LES/PUC-Rio

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

Padrões de Projeto(Design Patterns)

© LES/PUC-Rio

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 Object-Oriented 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


• Existem diversos adaptadores

© LES/PUC-Rio


O plug do laptop espera outra

interface

O adaptador converte uma interface na

outra

A tomada oferece uma interface

© LES/PUC-Rio


• Suponha que você tem um sistema que usa o componente A

Seu sistema

ComponenteA

Interfaces compatíveis

© LES/PUC-Rio


• Porém o fornecedor do componente A faliu…

• Você precisa utilizar o componente de outro fornecedor

Seu sistema

ComponenteA

© LES/PUC-Rio


• Porém, o fornecedor do componente B oferece uma interface incompatível com o seu sistema

Seu sistema

Componente B

Interfaces incompatíveis

© LES/PUC-Rio


• Para não correr riscos, você cria um adaptador

Seu sistema


Adaptador Componente B


Sem alteração de código

Sem alteração de código

Código novo

© LES/PUC-Rio


• 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”

Frameworks

© LES/PUC-Rio

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)

SpecificApplication Code

#1

© LES/PUC-Rio

Exemplo framework

• Framework de Análise e Persistência de dados

Hot-Spot #1Tipo de persistência

Hot-Spot #2Algoritmo de Análise

Implementação do Hot-Spot #1

Implementação do Hot-Spot #2

#1MySQL

#2Anal.

Estatística

Linha de Produto

© LES/PUC-Rio

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


• 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


Produtos

Domínio de Aplicação / Estratégia de Mercado

pertencem

Arquiteturacompartilham

Componentes

construídos por

© LES/PUC-Rio


© LES/PUC-Rio

Exemplo de LP

• Exemplo: Indústria Automobilística

• Carro– Caixa de Marcha

• Automática

• Manual

– Motor

• Diesel

• Gasolina

– Tipo de Motor

• 1.0

• 1.6

– ...

Pontos de Variação

Variantes

Agentes de Software

© LES/PUC-Rio

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

• Componentes

• ...

• Agentes de Software

Tempo

© 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


Exemplo de Trabalho Final

© LES/PUC-Rio

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

Documents

Projeto de Sistemas de Software (PSS) Prof. Carlos J. P. Lucena