Desenhando Componentes de Software com UML

Esta apresentação discute e fornece informações sobre o desenho de componentes de software utilizando a UML.
É abordado o reuso de software, principais técnicas, padrões e melhores práticas para desenho de componentes de software.
Esta apresentação é recomendada para quem atua como Arquiteto de Software e demais pessoas ligadas ao processo de desenvolvimento
de software.

1. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
1Arquitetura de Software
Desenhando Componentes de Software com UML®
RildoF Santos
[email protected]
[email protected]
Twitter: http://twitter.com/rildosan
Blog: http://rildosan.blogspot.com/

2. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
2
Quem sou
RildoF Santos
Coache Consultor de Gestão de Negócios, Inovação e Tecnologia para a Gestão 2.0, a Gestão Ágil.
A Gestão Ágil ajuda as empresas a responder mais rápido as demandas de negócio e mudanças. A Gestão 2.0, abrange
Planejamento Estratégico, Gestão por Processos Ágeis, Gestão de Projetos Ágeis, Tecnologia da Informação (Métodos
Ágeis), Inovação e Liderança.
Minha Experiência:
Tenho mais de 10.000 horas de experiência em Gestão de Negócios, Gestão de Inovação, Governança e Engenharia de
Software. Formado em Administração de Empresas, Pós-Graduado em Didática do Ensino Superior e Mestre em
Engenharia de Software pela Universidade Mackenzie.
Fui instrutor de Tecnologia de Orientação a Objetos, UML e Linguagem Java na Sun Microsystemse na IBM.
Conheço Métodos Ágeis (SCRUM, Lead, FDD e XP), Arquitetura de Software, SOA (Arquitetura Orientado a Serviço),
RUP/UP -Processo Unificado, Business Intelligence, Gestão de Risco de TI entre outras tecnologias.
Sou professor de curso de MBA da Fiape fui professor de pós-graduação da Faspe IBTA.
Possuo fortes conhecimentos de Gestão de Negócio (Inteligência de Negócio, Gestão por Processo, Inovação, Gestão de
Projetos e GRC -Governance, RiskandCompliance), SOX, BaselII e PCI;
E experiência na implementação de Governança de TI e Gerenciamento de Serviços de TI. Conhecimento dos principais
frameworks e padrões: ITIL, Cobit, ISO 27001 e ISO 15999;
Desempenhei diversos papéis como: Estrategista de Negócio, Gerente de Negócio, Gerente de Projeto, Arquiteto de
Software, Projetista de Software e Analista de Sistema em diversos segmentos: Financeiro, Telecomunicações, Seguro,
Saúde, Comunicação, Segurança Pública, Fazenda, Tecnologia, Varejo, Distribuição, Energia e Petróleo e Gás.
Possuo as certificações: CSM -CertifiedSCRUM Master, CSPO -CertifiedSCRUM ProductOwner, SUN Java Certified
Instrutor, ITIL Foundatione sou Instrutor Oficial de CobitFoundatione CobitGames;
Sou membro do IIBA-InternationalInstituteofBusiness Analysis(Canada)
Onde estou:
Twitter: http://twitter.com/rildosan
Blog: http://rildosan.blogspot.com/

3. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
3
Sobre o Apresentação
Esta apresentação discute e fornece informações sobre o desenho de componentes de
software utilizando a UML.
É abordado as principais técnicas, ferramentas e melhores práticas para desenho de
componentes de software.
Ela é recomendada para quem atua como Arquiteto de Software e demais pessoas ligadas
ao processo de desenvolvimento de software.
Para facilitar o entendimento do assunto, ela foi dividida em duas partes:
A primeira parte discute sobre componentes, abordagem CBD (ComponentBased
Delevopment–Desenvolvimento baseado em componentes), e reúsode software.
A segunda parte demonstra como desenhar os componentes utilizando a UML (versão 1.4)
-diagramas de componentes e de deployment.
Também é apresentado um estudo de caso para monstrarcomo identificar os componentes
de software.

4. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
4
-Introdução aos Componentes
-O que é Componentização
-Reúsode Software
-RAS (ReusableAssetSpecification)
Primeira Parte

5. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 20075
Apresentar e discutir a Componentes de Software, Reúsode Softwaree o padrãoRAS(mantido pela
OMG) .
Introdução
Componentes

6. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
Componentes no Mundo Real
O segmento de mercado vertical, já faz bom tempo que trabalhar com a
montagem de peças e partes é realidade, a industrias como: de
Automóvel, Construção Cível e Eletro-Eletrônica, são exemplos de como
produtos podem ser construídos (montados) e distribuídos.
E a industria de software....?
Componentes

7. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
E a industria de software....?
CBD(Desenvolvimento Baseado em Componentes)
representa a industrialização do desenvolvimento de
software.
Como em qualquer processo de manufatura que envolve
pontos que podem ser baseados em blocos pré-construídos,
aí temos a redução do tempo da produção, redução do custo
e aperfeiçoamento da qualidade.
Este principio aplica-se também ao desenvolvimento de
software, permitindo vantagem competitiva, no processo de
desenvolvimento, custo de produção e gerenciamento de
mudanças
Componentes

8. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
Evolução Modelo de Componentes:
Componentes

9. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
CBD
O que
são componentes?
Definição de Componentes
Componente é uma unidade funcional e coesa, que pode ser
distribuída, tem interfaces bem definidas, pode ser composto com
outros componentes para prover e usar serviços é independente de
linguagem, sistema operacional e sistema.
Componenteépartefísicaesubstituíveldeumsistemaquesatisfaz
osrequisitosdeumconjuntodeinterfaceseforneceasua
implementação;
Componentes

10. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
Elementos de um componentes:
Tem uma especificação
Componente
Pode ser distribuído
(“deployment”)
public class Item {
public Item(){
}
...
}
Aderência a
padrões
Tem uma
implementação
Pode ser empacotados
dentro de módulos
Componentes

11. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
CBD. UML Components. Elementos de um componentes:
Componente
Especificação:
Um componente requer uma descrição abstrata dos
serviços que ele oferece servindo como um contrato
entre o cliente e o fornecedor do serviço.
A especificação, além da relação das operações
disponíveis, orienta o cliente a como interagir com o
componente e informa as restrições dos estados que
componente pode assumirTem umaespecificação
Componente
Possibilidade de implementações:
Um componente deve suportar uma ou mais
implementações, as quais devem estar em
conformidade com a especificação.
A especificação deve ser flexível para que o
implementador possa escolher a linguagem adequada,
configuração adequada outros recursos que julgar
necessário.
publicclassItem {
publicItem(){
}
...
}
Tem uma implementação
Componentes

12. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
CBD. UML Components. Elementos de um componentes:
Componente
Padrão de Componente:
Um componente deve aderir a um modelo de
componentes. Os modelos de componentes suportam um
conjunto de serviços.
Os principais modelos de componentes são: Microsoft
COM+/DCOM, (OMG Corba CCM) e Sun EJB.
Aderência a padrões
Componente
Empacotamento:
Os componentes podem ser agrupados em unidades
funcionais conhecidas como pacotes (package),
permitindo que o conjunto de serviços oferecidos por eles
possa ser substituído por outro componente similar e que
possa ser distribuído e instalado.
Pode ser empacotados
dentro de módulos
Pode ser distribuído
(“deployment”)
Distribuído (Deployment):
A instalação dos componentes.
Componentes

13. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
Principais Padrões da Industria de Componentes
Componente
CCM Corba Component Model
Microsoft Components
EJB Enterprise JavaBeans
JavaBeans
Activex
Encapsulamento
Coesão
Polimorfismo
Responsabilidade
Contratos
Abstração
Componentes

14. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
Definição de Componentes
Benefícios:
Temos dois tipos:Técnicos e de Negócios
Técnico
•Melhor gerenciamento da complexidade.
(Decomposição funcional), a busca pela
simplicidade.
•Funcionalidade complexa que não é regra de
negócio pode ser concentrada em um
“Framework”
•Desenvolvimento e testes em paralelo
•Baixo acoplamento
•Consistência
•Reúso
Quais são os benefícios que são proporcionados pelo CBD ?
•Melhor qualidade do produto.
•Reduz Time-to-market.
•Melhor alocação de recursos humanos
•Pronto para responder a mudanças
•Redução de custo de desenvolvimento.
•Habilita a capacidade de Reúso
Negócio
Componentes

15. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
CBD. Desenvolvimento com simplicidade:
Componentes

16. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
Existem diversas técnicas que podem ser utilizadas
para alcançar tais expectativas, entre elas está o
“Reúso...”
Como conseguir alcançar estas expectativas ???
Introdução:
Expectativas no desenvolvimento de Software:
O que é reúso?
Reúsode software é a prática sistemática de desenvolver
ou atualizar novas aplicações a partir de “ativos de
software” pré-construídos nos quais são identificados
similaridades de requisitos e/ou arquiteturas com o que
está sendo desenvolvido.
Reúsode software portanto, não é apenas adotar os conceitos
do paradigma de OO, mas também, adotar uma estratégia
sistemática para tal.
Reúso

17. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
Devemos considerar 3 ações relevantes para a
implementação:
-Planejamento:
Planejamento refere-se à compreensão de como o
reúsopode contribuir para se atingir os objetivos da
organização como um todo;
-Disciplina:
Definição de medidas para mensurar e controlar o
sucesso do reúsoe ao estabelecimento de suporte
organizacional, técnico e orçamentário apropriados
-Envolvimento:
Preparação dos trabalhadores envolvidos para
executar o reúso.
Como implementar o reúsosistematizado ?
Introdução
Reúso

18. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
História do reúsode software:
Por que reusar software ?
Há 50 anos atrás, não havia software.
Hoje há aproximadamente mais de 100 bilhões de linhas de código em
bibliotecas de funções para todas as áreas especializadas.
“Seu problema” já foi resolvido por alguém antes.
Exercite “seu problema” desde uma pequena rotina até um módulo
inteiro de um sistema.
Reúso: “uma simples idéia”
Como nasceu o conceito de reúso ?
Reúso

19. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
Ativo:
Quais são os artefatos reusáveis ?
-Fragmentos de código de
programas;
-Documentações;
-Planos, estratégias e regras de
negócios;
-Código Fonte, Código executável;
-Objetos executáveis;
-Especificações;
-Requisitos;
-Serviços (SOA)
-Componentes;
-Projeto e Modelo (framework e
designer patterns);
-Módulos;
-Bibliotecas;
-APIs;
-Descrições de domínio;
-Arquiteturas de software;
-Diagramas
-Etc...
Devemos considerar que todos os artefatos que tenha um potencial de
reúsoseja classificado como um Ativo Digital.
Reúso

20. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
Quais são os artefatos reusáveis ?
O que não devemos considerar
Ativo Digital ?
Não devemos considerar coisas como:
-Software integrados, tal como: ERPs
-Legado: Softwares construídos na
“era” Mainframe
Reúso

21. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
Classificação das Formas de Reúso:
Quando um artefato é reusado, pode-se classificaresse reúsoquanto à
necessidade ou não de haver adaptações para se atender às requisições do
sistema e nos casos em que se façam necessárias essas adaptações, como
elas foram feitas.
. ReúsoCaixa Preta (blackboxreuse) -Quando os ativos são inseridos ao
sistema sem qualquer modificação.
. ReúsoCaixa Branca (whiteboxreuse) -Quando há necessidade de
reengenharia, ou seja, quando for necessário a modificação do corpo do ativo
para se obter as propriedades requeridas pelo sistema.
. ReúsoCaixa Cinza ou Cinzento (greyboxreuse) –Intermediário dos dois
anteriores, quando as alterações são feitas via configuração de parâmetros.
. ReúsoTransparente (glassboxreuse) –Em situações nas quais não se faz
necessário fazer alterações, mas para descobrir as propriedades do ativo é
preciso olhar dentro dele, pois a descrição disponível não traz informações
adequadas dessas propriedades.
Reúso

22. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
Estratégia de Implementação de um Ativo de Acordo com sua Forma
Reúso

23. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
Implementação de Reúso
A implementação de reúsorequer:
· Mudança nos Processos de Desenvolvimento:
Definição e análise de requisitos, projeto de alto nível e teste requerem
mudanças específicas para se levar em conta a disponibilidade dos ativos.
O gerenciamento de projeto também sofre impacto, assim como aspectos de
cronograma, custos e produtividade.
· Adição de Processos de Reúso:
Análise de domínio pode ou não ser usada para
direcionar a identificação de ativos reusáveis. Ativos podem ser menores ou
maiores, incluindo ou não projeto e requisitos. Podem ser produzidos e
mantidos por um grupo específico ou por projeto, antes de serem necessários
ou no momento que forem requisitados pela primeira vez.
Reúso

24. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
•Trabalhar fatores humanos:
Criar uma política de incentivos.
Uma ou mais técnicas podem ser usadas, como treinamento, eventos de
conscientização, grupos de discussões e notícias.
Dar prêmios isolados não são suficientes.
·Instalação de repositório:
Definir a política de implantação de repositório.
Como será implementado, quais os processos que serão usados, como
qualidade e gerenciamento de configuração. Pode ser usado uma ferramenta
específica ou um add-onpara implementar um sistema de gerenciamento de
configuração.
Implementação de Reúso
Reúso

25. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
Para administrar de forma eficiente um Repositório, ter procedimentos para:
-Gerenciamento de versões: um repositório pode conter várias versões de
um mesmo ativo e, sendo assim, é recomendável que haja algum mecanismo
para controlar essas versões e estabelecer o relacionamento entre elas.
-Gerência de Controle e Mudanças: é recomendável que sejam providas
algumas funcionalidades para se fazer o gerenciamento de modificações dos
ativos num repositório. Essas funcionalidades incluem procedimentos para
solicitação de alterações, discussões e permissão para as mesmas.
Implementação de Reúso
Reúso

26. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
Benefícios de se adotar a prática do reúso
A adoção da cultura de reúso pode trazer uma série de benefícios:
•Simplificação do desenvolvimento de software;
•*Redução de custos, prazos de entrega e esforço para se desenvolver e
manter o software;
•Aumento de produtividade;
•Desenvolvimento de software de maior qualidade, e portanto, de maior
confiabilidade;
•Redução de erros;
•Conhecimentos sobre sistemas e como construí-los podem ser
compartilhados;
•Facilidade em aprender sobre arquiteturas de sistemas
•Compartilhamento de conhecimentos adquiridos com a experiência, ou
seja, compartilhamento das melhores práticas.
Reúso

27. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
Benefícios de se adotar a prática do reúso. Exemplo:
Redução de Custos:
*Quando um componente é desenvolvido aplicando-se técnicas de reúso, este precisa
ser usado de três a cinco vezes em aplicação para recuperar seu investimento inicial.
Componentes podem custar de 1.5 a 3.0 vezes mais para criar um componente com
suporte a reúso, do que os componentes sem características de reúso.
Componentes reusáveis têm custo de apenas um quarto (1/4) do valor de
desenvolvimento de novo componente.
Reúso

28. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
28
Ciclo de Desenvolvimento focado Domínio do Problema
Requisitos
Análise
Projeto
Construção
Aplicação
Projeto 1 Projeto 2
Requisitos
Análise
Projeto
Construção
AplicaçãoReúso na maioria das
vezes de programas ou
partes do código
Cenário desenvolvimento focado em Projeto
Reúso

29. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
29
Ciclo de Desenvolvimento focado em Reúsode Componentes
Requisitos
Análise
Projeto
Construção
Planejamento
e preparação
para reúso
Produto
Repositório
Registro
Seleção
+
Modificação
Novos Projetos
Cenário desenvolvimento focado em Reúso
Reúso

30. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
30
As camada de Domínios das classes:
Uma aplicação que segue a orientação a objetos conterá classes de quatro
principais domínios:
–O domínio da Aplicação;
–Domínio de Negócio;
–Domínio da Arquitetura e
–Domínio Base.
Cada um destes domínios tem inúmeros grupos de classes dentro deles:
Domínio da Aplicação
Domínio do Negócio
Domínio da Arquitetura
Domínio Base
Reúso

31. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
31
Domínio da Aplicação:
•Contém classes importantes para uma aplicação. Por exemplo: classes de regras de negócios de
uma aplicação.
Domínio do Negócio:
•Contém classes importantes para um tipo de negócio, tais como: Financeiro, Seguros e etc. Estas
classes têm um conjunto de regras válidas para todo o segmento.
Domínio da Arquitetura:
•Contém classes importantes para uma arquitetura de implementação. Por exemplo, classes de
interface com usuário, classes de manipulação de banco de dados e classes de comunicação entre
computadores e outros dispositivos.
Domínio Base:
•Contém classes importantes para todas as arquiteturas, áreas de negócios e aplicação. Por
exemplo classes bases, classes estruturais e etc. Estas classes geralmente são tipos de dados,
coleções e etc.
Geralmente estas classes estão atrelados a linguagem de programação.
As camada de Domínios das classes:
Reúso

32. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
32
Domínios das Classes
Domínio da Aplicação
Domínio do Negócio
Domínio da Arquitetura
Domínio Base
Grau de Reusibilidade
Alto reúso
Médio reúso
Baixo reúso
As camada de Domínios das classes vsReúso:
Reúso

33. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
Falhas no processo...
Alguns fatores que podem ser considerados como determinantes de
fracassos no processo de implementação da cultura de reúsosão:
•Não envolvimento e comprometimento por parte das pessoas e
principalmente pela alta gerência das empresas;
•Não introdução de processos de qualificação e classificação;
•Não alteração de processos diferentes do reúso, como análise de
requisitos, de projeto;
•Nenhuma preocupação ou direcionamento para fatores humanos,
como treinamento e motivação e
•Entendimento da empresa que repositório ou tecnologia orientada a
objetos tratados isoladamente, sem ações complementares, significam
reúso.
Reúso

34. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
Como evitar as falhas ?
1. Potencial de Reúso
Avalie o potencial de reúso, o qual é maior quando as empresas
desenvolvem
produtos de software similares que evoluem com o tempo e são mais ou
menos
adaptados para cada cliente.
2. Capacidade de Reúso
Consiga um comprometimento da alta gerência para obter recursos
necessários e
poder para:
· Mudar processos de desenvolvimento
· Adicionar processos de reúso
· Trabalhar fatores humanos
· Instalar um repositório
· Definir pessoas chaves para o reúso
A ordem em que esses itens aparecem não é importante, todos esses
aspectos devem ser executados. Se dois ou mais deles não forem
direcionados, o fracasso é bem provável de acontecer.
Reúso

35. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
Considerações Finais:
Reúsonão é uma tecnologia e sim procedimento de trabalho.
Os resultados são a médio e a longo prazo. A implementação do reúsotem
custo inicial, pois é preciso mudar a empresa e as pessoas para adoção da
cultura do reúso.
Os ganhos são maiores quando há escala.
Devemos fazer reúsode todos os artefatos e não somente de componentes
de software.
O comprometimento da equipe é fundamental.
Gerenciamento do repositório de componentes exige cuidado especial, pois
nele encontra-se toda a base de conhecimento da empresa.
"No SilverBullet” (F. Brooks)
Reúso

36. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 200736
RAS (ReusableAssetSpecification)
RAS -ReusableAssetSpecification
Especificação:
http://www.omg.org/cgi-bin/doc?formal/2005-11-02
Mantido pela OMG (www.omg.org)
Patrocinadores:
-IBM Rational
-LogicLibrary
-Borland
-Componentsource
Alguns conceitos:
-Ativo: Alto nível de abstração
-Artefato: Qualquer produto que faz parte
ou decorre do ciclo de desenvolvimento de
software, tais como: Documentos de
Requisitos, Modelos, Código fonte,
Templates, fragmento de código,
componentes, bibliotecas, APIs, scripts e
etc.
Geralmente um ativo está associado a um
arquivo.
-XML SchemaandMOF XMI
Tipos de Ativos Reusáveis de Software
Ativos

37. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 200737
Tipos de Ativos:
O RAS utilização de 3 critérios para a classificação de um ativo:
Granularidade: determina o número de problemas endereçado por um ativo. Pode ser pequena,
quando trata de um único problema. Um algoritmo para cálculo do dígito verificador do CPF ou uma
combobox, por exemplo. Ou pode ser grande, apresentando soluções para um ampla gama de
problemas.
Visibilidade(Variabilidade): indica quanto de um ativo pode ser visualizado e manipulado. Apesar de
algumas diferenças na nomenclatura utilizada, é consenso que existem 4 níveis distintos de
visibilidade / variabilidade de um ativo:
Caixa Preta: o ativo não pode ser alterado e seu interior não pode ser visualizado. Normalmente
representa código binário –módulos executáveis adquiridos de terceiros.
Caixa de Vidro (ou Limpa): detalhes da implementação são expostos (via modelos,
documentação ou até mesmo o código-fonte), mas o ativo não pode ser alterado. A
transparência visa exclusivamente o apoio na utilização daquele software.
Caixa Cinza: interior do ativo é parcialmente exposto e manipulado, normalmente através de
parâmetros. São componentes ou serviços desenvolvidos com o objetivo de serem reutilizados.
Caixa Branca: o ativo oferece total visibilidade e variabilidade. Além da total disponibilidade do
código-fonte, ativos com este nível de visibilidade também apresentam seus requisitos, casos
de uso, modelos, e todos os demais artefatos relevantes gerados no processo de
desenvolvimento.
Articulação: descreve o grau de completitude de um determinado ativo. Ou seja, o quão pronto um
ativo está para a solução de um dado problema. Um conjunto de requisitos, por exemplo, está longe
de solucionar efetivamente o problema. Diz-se que seu grau de articulação é baixo. Já um
componente em sua forma executável apresenta um alto grau de articulação.
Fonte: http://www.pfvasconcellos.eti.br/blog/2006/12/21/ativos-de-software/
RAS (ReusableAssetSpecification)

38. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 200738
Um “ativo digital” tem um conceito parecido como de item do
patrimônio de uma empresa, ou seja, uma etiqueta que facilita a sua
identificação.
O RAS foi criado exatamente para funcionar como essa „etiqueta de
patrimônio‟ para ativos de software reutilizáveis. Ele é estruturado
em 2 categorias: Núcleo(Core RAS) e Perfis.
-Núcleo:
O núcleo representa todos os elementos fundamentais de um ativo.
-Perfis:
Os perfis são utilizados para descrever características específicas de
um ativo.
Exemplo:
Podemos ter um ativo que gera orçamentos para o seguro de vida;
este ativo possui dois perfis distintos: um para sua versão off-line e
outro para a versão web service. Uma etiqueta RAS básica,
descrevendo apenas o núcleo.
RAS (ReusableAssetSpecification)

39. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 200739
Core RAS UML
Model
for XML
Schema
RAS (ReusableAssetSpecification)

40. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
Como evitar as falhas ? Mitos e lendas...
Muitas empresas acreditam que a adoção da
orientação da orientação a objetos sozinha pode
prover “reúso”...
Alguns empresas imaginam que reúso somente
alcançará o sucesso se implementado em
empresas que desenvolvem software em larga
escala...
Outras empresas não acreditam que seja possível a
implementação da cultura de “reúso”...
Reúso

41. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
41
-Processo de Desenvolvimento de Software
-UML e a visão 4+1
-Workflows
-Workflow de Design (Arquitetura)
-Road da Arquitetura
-Diagrama de Deployment
-Diagrama de Componentes
-Estudo de Caso: Identificando Componentes
Segunda Parte

42. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 200742
Apresentar e discutir a Arquitetura de Software, explorando o contexto de Reúso. Arquitetura é parte
do Workflow de Design, nesta fase criamos os componentes, modelos físicos e como serão distribuídos.
Os principais diagramas (UML) são:
-Diagrama de Deploymente Diagrama de Componentes.
Workflow de Design (Arquitetura):
Introdução

43. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
43
Concepção Elaboração Construção Transição
Inicial E #1 E #2 C #1 C #2 T #1 T #2C #3
Modelagem Negócios
Requisitos
Análise e Design
Implementação
Testes
Controle de Mudanças
Gerência de projeto
Ambiente
Fases
Workflows
Processo Unificado (Fases e Workflows)
Workflow de Design (Arquitetura):

44. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 200744
Introdução. UML, Visões:
Conceitual Físico
Visão de
Projeto
Funcionalidade
Vocabulário
Visão da
Implementação
Codificação
Montagem
Visão do
Processo
Desempenho
Escalabilidade
Throughput
Visão da
Implantação
Topologia do Sistema
Distribuição
Instalação
Visão de
Caso de Uso
Workflow de Design (Arquitetura):

45. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 200745
Big Picture. Requisitos e Análise
Vocabulário de
Conceitos de Negócio
Modelo Conceitual
Workflow Análise
Casos de Uso
Engenharia de Requisitos
Requisitos Funcionais
Requisitos Não
Funcionais
Análise de Requisitos Especificação de Requisitos
(Visão de Caso de Uso)
Levantamento de Dados
Documento
de Visão
Business Case
Arquitetura Inicial
Workflow de Design (Arquitetura):

46. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
46
Workflow, Artefatos e Papéis:
Documento de Visão
Especificação de Requisitos
(Casos de Uso)
Vocabulário do Sistema
Modelo Conceitual ou Modelo
de Domínio
Documento de Requisitos
Análise
Requisitos
Analista de Sistema
Analista de Negócios
Analista de Requisitos
Analista de Sistema
Analista de Negócios
PapéisArtefatosWorkflow
Workflow de Design (Arquitetura):
Requisitos e Análise

47. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
47
Big Picture. Design
Modelo Conceitual
Análise
Diagrama de Classes
Projeto (Visão Lógica)
 : visitante
: Categoria : Produto : Catalogo : FormBusca
exibirCategoria( )
exibirProduto( )
selecionarCategoria
selecionarProduto( )
getDescricao( )
getDescricao( )
getQuantidade( )
Receber Pedido
Preencher Pedido
Receber Pagam ento
Enviar Fatura
Entrega durante
a noite
Entrega Regular
[pedido urgente] [senão]
Encerrar Pedido
Entrega
Especificação de Requisitos
(Visão de Caso de Uso)
Workflow de Design (Arquitetura):

48. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
Workflow, Artefatos e Papéis:
48
Digrama de
Seqüência ou de
Colaboração
Diagrama de Classes
Diagrama de Atividades
Projeto
Analista de Sistema
Projetista de Software
PapéisArtefatosWorkflow
Diagrama de Estados
Arquiteto
Design
Workflow de Design (Arquitetura):

49. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
49
Big Picture. Design &Arquitetura
Diagramas
Projeto (Visão Lógica)
 : visitante
: Categoria : Produto : Catalogo : FormBusca
exibirCategoria( )
exibirProduto( )
selecionarCategoria
selecionarProduto( )
getDescricao( )
getDescricao( )
getQuantidade( )
Receber Pedido
Preencher Pedido
Receber Pagam ento
Enviar Fatura
Entrega durante
a noite
Entrega Regular
[pedido urgente] [senão]
Encerrar Pedido
Entrega
Projeto (Visão de Componentes e
Visão de Deployment)
Diagrama de Componentes
Diagrama de Deployment
Arquitetura
Workflow de Design (Arquitetura):

50. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
Workflow, Artefatos e Papéis:
50
Digrama de
Componentes
Diagrama de
Deployment
Arquitetura
Analista de Sistema
Projetista de Software
PapéisArtefatosWorkflow
Arquitetura
Arquiteto de Software
Modelo de Arquitetura
Workflow de Design (Arquitetura):

51. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
51
Arquitetura: Road Map
Fazer Diagramas
Modelo de
Especificação
Documentos
de Requisitos
Caso de Uso
Fazer Modelo de
Arquitetura
Digrama de
Componentes
Digrama de
Deployment
View ControllerModel Resources
JSP/HTML Servlet EJB
Banco de
Dados
Workflow de Design (Arquitetura):
As principais atividadese artefatossão:
Atividades:
-Fazer Diagrama de Deployment; Fazer Diagrama de Componentes; Fazer o Modelo de Arquitetura
Artefatos:
-Diagrama de Deployment; Diagrama de Componentes e Modelo de Arquitetura

52. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
52
Fazer Modelo Arquitetura
Fazer Diagrama de
Componentes
Refinar Modelo de
Arquitetura (RNFs)
Refinar o Modelo
de Especificação
Arquitetura. Atividades e Passos:
Modelo de
Arquitetura
Digrama de
Componentes
Fazer Diagrama de
Deployment
Selecionar uma
Arquitetura
Digrama de
Deployment
Workflow de Design (Arquitetura):

53. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
53
O que é Diagrama de Deployment?
Variações tradução:
•Diagrama de Deployment<=> Diagrama de Implantação
•Diagrama de Deployment<=> Diagrama de Distribuição
É um diagrama que exibe a arquitetura física do hardware e do software no sistema.
Pode apresentar os computadores e periféricos, juntamente com as conexões que eles
estabelecem entre si. Podemos mostrar também os tipos de conexões entre esses
computadores.
Especifica-se os componentes executáveis e objetos que são alocados para exibir quais
unidades de software são executados e quais computadores.
O diagrama de deploymentdemonstra a arquitetura “runtime”de processadores,
dispositivos físicos e de software que executam no ambiente onde o sistema
desenvolvido será utilizado. É o último diagrama da topologia do sistema, descrevendo
a estrutura de hardware e software que executam em cada unidade.
Diagrama de Deployment
Workflow de Design (Arquitetura):

54. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
54
processador
Elementos:
Processor (Processador): É qualquer máquina que possua a capacidade de
processamento. Os servidores, estações de trabalho por exemplo.
Dispositivo
Diagrama de DeploymentServidor
Device (Dispositivo): É qualquer máquina com finalidade ou finalidade limita. Os
dispositivos são os itens como impressoras, roteadores, raids, storages, scanners,
leitoras de código de barra e etc.Impressora
Workflow de Design (Arquitetura):

55. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
55
Elementos:
Connection(conexão): A conexão é o vinculo entre processadores e dispositivos.
Geralmente representam as conexões de rede físicas (rede local ou distribuída).
Diagrama de DeploymentServidor
Impressora
Cliente <<TCP/IP>>
<<RS 232>>
conexão
Dispositivo
(Nó)
Processador
(Nó)
estereotipo
Workflow de Design (Arquitetura):

56. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
56
Elementos:
Os processadores e os dispositivos podem ser chamados de nó. Um nóé um elemento
físico que existe em tempo de execução e representa um recurso computacional.
Diagrama de DeploymentImpressora
WebBrowser
<<Cliente>>
<<RS 232>>
Apache
<<WebServer>>
<<HTTP>>
JBoss
<<Application Server>>
Oracle
<<Banco de Dados>>
Cliente
<<Client-Server>>
<<RMI>>
Nós
Workflow de Design (Arquitetura):

57. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
57
Diagrama de Componentes. Introdução:
Os componentes são utilizados para a modelagem de coisas físicas que podem residir em
nó, como executáveis, bibliotecas, tabelas, arquivos e documentos.
Um componente tipicamente representa o pacote físico de elementos lógicos, como
classes, interfaces, colaborações.
Bons componentes definem abstrações com interfaces bem-definidas, desta forma é
possível atualização de componentes, ou seja, trocar os componentes mais velhos por
outros componentes mais novos ou por novas versões.
Componente
A
Componente
B
Dependência
Componente
genérico
Nome do
componente
Workflow de Design (Arquitetura):

58. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
58
Diagrama de Componentes
O que é um Diagrama de Componentes?
É um diagrama que exibe o sistema por um lado funcional, expondo as relações entre
seus componentes e a organização de seus módulos durante sua execução.
O diagrama de componente descreve os componentes de software e suas dependências
entre si, representando a estrutura do código gerado. Eles são tipicamente os arquivos
implementados no ambiente de desenvolvimento.
Diagrama de componente representa uma visão física, é um pedaço de software de
sistema e seus relacionamentos.
Quando um componente colabora com outro componente, está colaboração é ilustrada
com uma dependência entre o componente cliente e o componente de serviço.
Reserva
Service_
stub
ReservaService
ReservaUI
Component
Dependência
Interface
Room
Workflow de Design (Arquitetura):

59. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
59
Diagrama de Componentes. Definições:
Componente:
Um componente é a parte física e substituível de um sistema ao qual se adapta e fornece a
realização de um conjunto de interfaces.
Interfaces:
Uma interface é coleção de operações utilizadas para especificar um serviço de uma classe
ou de um componente. O relacionamento entre componente e interface é muito importe.
As tecnologias mais populares usam interfaces na implementação de componentes, tais
como:
-EJB (Enterprise Java Beans);
-Corba(CCM) e
-Microsoft DCOM/COM+.
Workflow de Design (Arquitetura):

60. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
60
Catalog
Business
Delegate
Catalog
Home
Stub
CatalogHome
Catalog
Remote
Stub
CatalogRemote
Catalog
EJB
Home
Catalog
EJB
Object
Catalog
Bean
CatalogRemote
CatalogRemote
CatalogHome
Catalog.jsp
Diagrama de Componentes. Exemplo:
Workflow de Design (Arquitetura):

61. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
61
Diagrama de Componentes
Tipos de Componentes:
Existem três tipos de componentes:
-Componentes de Implantação: São os componentes necessários para montar um
sistema executável, como as DLLse os arquivos EXEs. A definição da UML para
componentes é abrangente, inclui componentes mais populares (COM+, CCM e EJB),
além de modelos alternativos como páginas web, tabelas de banco de dados e etc...
CheckIT.exe
{versão 1.}
Disk.dll
Video.dll
Floppy.dll
Workflow de Design (Arquitetura):

62. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
62
Diagrama de Componentes
Tipos de Componentes: (continuação)
-Componentes do Produto do Trabalho: Esses componentes são essencialmente o é
parte do processo de desenvolvimento, formados por arquivos de código fontes, arquivos
de dados, ícones. Esses componentes não fazem parte (diretamente) em sistema
executável, mas são os produtos de desenvolvimento, usados para criação do sistema
executável.
Cliente.class
Conta.jar
{versão 1}
Historico.class
Conta.class
Conta.java
-Componentes de Execução: Esses componentes são criados como uma
conseqüência de um sistema em execução, como um componente COM+, que é sofre
“instance” a partir de uma DLL.
Workflow de Design (Arquitetura):

63. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
63
Diagrama de Componentes. Elementos:
Elementos:
A UML define cinco estereótipos-padrão que se aplica aos componentes:
1 -Executável:
Especifica um componente que poderá ser executado em um nó
2 -Biblioteca:
Especifica uma biblioteca de objetos estática ou dinâmica
3 -Tabela:
Especifica um componente que representa uma tabela de banco de dados
5 -Arquivo:
Especifica um componente que representa um documento contendo código-fonte ou
dados
6 -Documento:
Especifica um componente que representa um documento.
Workflow de Design (Arquitetura):

64. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
64
Diagrama de Componentes
Tipos de Componentes:
-Componente: O ícone de componente representa um módulo (pedaço) de software
com uma interface bem definida. Na especificação de componente definimos o
estereótipo como: ActiveX, Applet, Application, DLL e EXE.
Nome do
Componente
Componente
genérico
-Especificação e corpo do subprograma: Estes ícones representam a especificação
visível de um subprograma e o seu corpo de implementação. Um subprograma costuma
ser uma coleção de sub-rotinas. Os subprogramas não contém definições de classe.
NewSubprogSpec NewSubprogBody
Workflow de Design (Arquitetura):

65. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
65
Diagrama de Componentes
Tipos de Componentes:
-Programa Principal: Este ícone representam o programa principal. Um programa
principal que contém a raiz de um programa. Na linguagem Java seria o programa que
tem o método “main”.
MainProgram
Programa princial
(método main)
-Especificação e corpo do pacote: Um pacote é a implementação de uma classe. Uma
especificação de pacote constitui-se em um arquivo de cabeçalho, o qual contém as
informações referentes ao protótipo de função para a classe.
Package Specification Package Body
Na linguagem C++, as
especificações de pacote são os
arquivos .h(header). Em Java
usamos o ícone de especificação
de pacote para representar os
arquivos .java
Um corpo de pacote pode
apresentar o código para as
operações da classe. Em C++,
os corpos de pacotes são os
arquivos
.cpp
Workflow de Design (Arquitetura):

66. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
66
Diagrama de Componentes
Tipos de Componentes:
-Especificação e corpo da tarefa: Estes ícones representam os pacotes que possuem
linhas independentes de controle. Uma arquivo executável é geralmente representado
como uma especificação de tarefa com uma extensão .exeNewTaskSpec NewTaskBody
Componente
genérico
Interface
Além de modelar o componente propriamente dito, podemos modelar o relacionamento
entre o componente e sua interface. Veja o exemplo abaixo:
Workflow de Design (Arquitetura):

67. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
67
Arquitetura.Diagrama de Componentes. Exemplo:
Neste exemplo criaremos um diagrama de componentes para a funcionalidade
“cesta de compra”. Neste momento identificaremos as classes que são necessárias
para realizar o caso de uso “adicionar item na cesta de compra”. Como alguns
casos de usos são embutidos, novos componentes serão adicionados ao
diagrama. A tecnologia deste exemplo é Java.Boundary
Services
Entities
Component view
Visão principal do Diagrama de Componentes
Workflow de Design (Arquitetura):

68. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
68
Arquitetura.Diagrama de Componentes. Exemplo:
Todos os componentes do pacote Entities. Esses são os componentes que conterão as
classes de entidades.
Component view
As classes EntidadesEntities
Cesta
Cesta Item Produto
Workflow de Design (Arquitetura):

69. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
69
Arquitetura.Diagrama de Componentes. Exemplo:
Todos os componentes do pacote Services. Esses são os componentes que conterão as
classes de serviços ou de controle.
Component view
As classes de Serviços ou Controle
CestaService
ProdutoServiceServices
Workflow de Design (Arquitetura):

70. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
70
Arquitetura.Diagrama de Componentes. Exemplo:
Todos os componentes do pacote Boundaries. Esses são os componentes que conterão
as classes de Boundaries (ou de interface com usuário).
Component view
As classes de Interfaces
CestaInterfaceBoundary
Workflow de Design (Arquitetura):

71. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
71
Arquitetura.Diagrama de Componentes. Exemplo:
Uma visão dos componentes e relacionamentos
CestaInterface
MainProgram
CestaService
ProdutoService
Cesta
Cesta Item
Produto
Workflow de Design (Arquitetura):

72. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
72
Arquitetura.Diagrama de Componentes. Exemplo:
Um novo exemplo, o cenário fazer Reserva de apartamento.
ReservaUI
Menu Principal
ReservaService
ClienteService
Cliente Reserva Apartamento
ApartamentoService
Model
Controller
View
Workflow de Design (Arquitetura):

73. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
73
Componentes
Componentes:
Componentes são grupos de classes que representam uma funcionalidade
dentro de sistema.
Componentes são identificados usando coesão e acoplamento. Grupos de
classes que exigem alta coesãoe baixo acoplamentoformam um
componente.
Como identificar os componentes ?
No Workflow de Arquitetura os componentes são
desenhados da seguinte forma:
•O Diagrama de Classe (Modelo de Especificação) é
revisado e grupos de classes são identificados
usando as técnicas de coesão(alta coesão)e
acoplamento (baixo acoplamento)
•Este grupos representaram os componentes.
Diagrama de Componentes. Identificação de Componentes:
Como faço
componentes
reusáveis ?
Componentes: Estudo de Caso

74. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
74
Conceitos: Acoplamento e Coesão
Independência
Funcional:
•Coesão e
•Acoplamento
Independência Funcional
Conceito que está diretamente relacionado a modularidade, abstração e
encapsulamento de informação.
Principais características:
•função de propósito único.
•Interfaces simples quando visto de outras partes da estrutura do
programa.
•É medida usando-se dois critérios qualitativos: coesãoe
acoplamento.
Coesão e Acoplamento ajudaram na divisão de classe dentro
de componente.
Componentes: Estudo de Caso

75. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
75
Coesão (High Cohesion)
É uma medida de força funcional relativa de um módulo.
Uma classe coesiva executa uma única tarefa, exigindo pouca
interação com outras classes ou objetos. Alta coesão é o desejável.
Como manter a alta coesão ?
-Solução: Atribuir uma responsabilidade de forma que a coesão
permaneça alta.
Como manter a complexidade sob controle ?
Em termos de projeto orientado a objetos, a coesão (ou mais
especificamente, coesão funcional) é uma medida de quão
fortemente relacionadas e focalizadas são as responsabilidades
de uma classe.
Uma classe com responsabilidade altamente relacionadas e que
não executa um formidável volume de trabalho tem coesão alta.
Conceitos: Acoplamento e Coesão
Componentes: Estudo de Caso
Independência
Funcional:
•Coesão e
•Acoplamento

76. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
76
Coesão: (continuação)
Uma classe com coesão baixa faz muitas coisas não-relacionadas, ou
executa demasiado trabalho. Tais classes são indesejáveis, elas sofrem
dos seguintes problemas:
-São difíceis de compreender;
-São difíceis de reusar;
-São difíceis de manter;
-São muito sensíveis a mudança;
Classes de coesão baixa representam, geralmente, uma abstração de
“grande granularidade” ou atribuíram responsabilidades que deveriam ter
sido delgadas a outras classes ou objetos
Conceitos: Acoplamento e Coesão
Componentes: Estudo de Caso
Independência
Funcional:
•Coesão e
•Acoplamento

77. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
77
Coesão: (continuação)
Exemplo:
Neste exemplo é
demonstrado a baixa
coesão, uma vez que a
classe Nota Fiscal
assume a
responsabilidade de
fazer o cálculo dos
imposto
NotaFiscal
-número
-data emissão
-tipo
+calcularImposto()
+getNumero
+setNumero
....
NotaFiscalItem
-item[ ]
-quantidade
+getQuantidade()
+setQuantidade()
...
Produto
-codigo
-descrição
+setCodigo()
+getCodigo()
Cliente
-codigo
-nome
+getCodigo()
+setCodigo()
+getNome()
Conceitos: Acoplamento e Coesão
Tributo
-codigo
-nome
Independência
Funcional:
•Coesão e
•Acoplamento
Componentes: Estudo de Caso

78. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
78
Independência
Funcional:
•Coesão e
•Acoplamento
Coesão: (continuação)
Exemplo:
Solução é delegara
responsabilidade de
cálculo de imposto para
uma classe especializada
neste assunto (usamos
aqui o mecanismo de
delegação). Desta forma
teremos uma alta coesão.
NotaFiscal
-número
-data emissão
-tipo
+getNumero
+setNumero
....
NotaFiscalItem
-quantidade
+getQuantidade()
+setQuantidade()
...
Produto
-codigo
-descrição
+setCodigo()
+getCodigo()
+gerProduto
Cliente
-codigo
-nome
+getCodigo()
+setCodigo()
+getNome()
+get/cliente()
CalculoImposto
+calcularImposto()
Conceitos: Acoplamento e Coesão
Tributo
-codigo
-nome
Componentes: Estudo de Caso

79. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
79
Independência
Funcional:
•Coesão e
•Acoplamento
Acoplamento (Low Coupling)
É uma medida da interdependência relativa entre as classes.
Depende da complexidade de interface entre as classes.
Baixo acoplamento é o desejável
Como manter o baixo acoplamento ?
-Solução: Atribuir uma responsabilidade de forma que o
acoplamento permaneça fraco
Como suportar uma dependência baixa e aumentar o
reúso?
O acoplamento é uma medida de quão fortemente uma classe
está ligada a uma ou mais classes, tem conhecimento das
mesmas ou depende delas.
Uma classe com acoplamento baixo (fraco) não é dependente
de muitas classes.
Conceitos: Acoplamento e Coesão
Componentes: Estudo de Caso

80. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
80
Independência
Funcional:
•Coesão e
•Acoplamento
Acoplamento (continuação)
Uma classe com acoplamento alto (forte) depende de muitas outras
classes. Tais classes são indesejáveis; elas sofrem dos seguinte
problemas:
•Mudança em classes relacionadas forçam mudanças locais
•Mais difícil de compreender isoladamente
•Mais difícil de reusar porque o seu uso requer a presença adicional
das classes que ela depende.
Benefícios:
•Não afeta por mudanças em outros componentes
•simples de entender
•conveniente para o reúso.
Conceitos: Acoplamento e Coesão
Componentes: Estudo de Caso

81. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
81
Acoplamento
Conceitos: Acoplamento e Coesão
<<interface>>
iPessoa
Cliente
Realização
Relacionamento de Realização
Problema:
A classe Cliente realiza a interface iPessoa
(isto quer dizes que todos os métodos
assinados na interface deve ser implementado
na classe) Uma vez que se declare uma nova
assinatura de método na interface iPessoa
será necessário implementar este novo
método na classe Cliente.
<<interface>>
iPessoa
Cliente
Herança
Solução:
Criação de nova classe PessoaAdapter esta classe
se relacionará com a interface iPessoa, desta forma
todas as modificações ou novos implementações
serão feitas nesta classe.
Desta forma reduziremos o acoplamento entre a
interface e a classe Cliente
PessoaAdapter
Realização
Componentes: Estudo de Caso

82. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
82
Exemplo:
A partir do diagrama de classe, tentamos agrupar classes usando técnicas de coesão e acoplamento.
Diagrama de Componentes
Componentes: Estudo de Caso

83. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
83
Exemplo:
Temos o seguinte resultado:
Diagrama de Componentes
Componentes: Estudo de Caso

84. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
84
Exemplo 2: Digrama de Classes
Diagrama de Componentes
Componentes: Estudo de Caso

85. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
85
Exemplo 2:
A partir do diagrama de classe,
agrupar classes usando os
conceitos de coesão
e acoplamento.
Pedido
Cesta de Compra
Produto
FormaPagto
Componentes: Estudo de Caso
Diagrama de Componentes

86. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
86
Exemplo 2: Diagrama de Componentes
Diagrama de Componentes
Cesta
Pedido
Produto
FormaPagto
Componentes: Estudo de Caso
Pedido
Cesta de Compra
Produto
FormaPagto

87. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
87
Referências:
Software Reuse: Architecture, ProcessandOrganizationfor Business Success
Autor Ivar Jacobson
Domain-DrivenDesign: TacklingComplexityin theHeartofSoftware
Autor Eric Evans
ManagingSoftware Reuse
Autor Wayne C. Lim
ExecutableUML: A Foundationfor Model-DrivenArchitecture
Autores: Stephen J. Mellore Marc J. Balcer
UnifiedModelingLanguageUserGuide, The(2º. edição)
Autores: GradyBooch, James Rumbaughe Ivar Jacobson
Component-BasedSoftware Engineering: PuttingthePiecesTogether
Autores: George T. Heinemane William T. Councill
ComponentSoftware: BeyondObject-OrientedProgramming (2º. Edição)
byClemensSzyperski
www.omg.org/uml
www.componentsource.com
Tags:Componentes de Software, Reuso de Software e Arquitetura de Software
Para ir além:WebService, SOA (Arquitetura Orientada a Serviços)

88. RildoF Santos ([email protected])Versão 7.0
Desenhado Componente de Software com UML
Todos os direitos reservados e protegidos © 2006 e 2007
88Arquitetura de Software
Desenhando Componentes de Software com UML®
RildoF Santos
[email protected]
[email protected]
Twitter: http://twitter.com/rildosan
Blog: http://rildosan.blogspot.com/