Desenhando Componentes de Software com UML

Rildo F Santos ([email protected])Versão 7.0

Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML

Todos os direitos reservados e protegidos © 2006 e 20071Arquitetura de Software

Desenhando Componentes de Software com UML®

Rildo F Santos

[email protected]

[email protected]

Twitter: http://twitter.com/rildosan

Blog: http://rildosan.blogspot.com/

mailto:[email protected]?subject=Contato




Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML

Todos os direitos reservados e protegidos © 2006 e 20072

Quem souRildo F Santos

Coach e 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 Microsystems e 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 Fiap e fui professor de pós-graduação da Fasp e 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, Risk and Compliance), SOX, Basel II 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 - Certified SCRUM Master, CSPO - Certified SCRUM Product Owner , SUN Java Certified

Instrutor, ITIL Foundation e sou Instrutor Oficial de Cobit Foundation e Cobit Games;

Sou membro do IIBA-International Institute of Business Analysis (Canada)

Onde estou:



http://twitter.com/rildosan


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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 (Component Based

Delevopment – Desenvolvimento baseado em componentes), e reúso de 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 monstrar como identificar os componentes

de software.


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


- Introdução aos Componentes

- O que é Componentização

- Reúso de Software

- RAS (Reusable Asset Specification)

Primeira Parte


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML

Todos os direitos reservados e protegidos © 2006 e 2007 5

Apresentar e discutir a Componentes de Software , Reúso de Software e o padrão RAS (mantido pela

OMG) .

Introdução

Componentes


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


Evolução Modelo de Componentes:

Componentes


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


CBD

O que

são componentes?

Definição de ComponentesComponente é 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 é parte física e substituível de um sistema que satisfaz

os requisitos de um conjunto de interfaces e fornece a sua

implementação;

Componentes


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


CBD. UML Components. Elementos de um componentes:

ComponenteEspecificaçã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 uma especificação

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

public class Item {

public Item(){

}

...

}

Tem uma implementação

Componentes


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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

ComponenteEmpacotamento:

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


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


CBD. Desenvolvimento com simplicidade:

Componentes


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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úso de 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úso de 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


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


Devemos considerar 3 ações relevantes para a

implementação:

- Planejamento:

Planejamento refere-se à compreensão de como o

reúso pode 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úso e 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úso sistematizado ?

Introdução

Reúso


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


História do reúso de 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


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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úso seja classificado como um Ativo Digital.

Reúso


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


Classificação das Formas de Reúso:

Quando um artefato é reusado, pode-se classificar esse reúso quanto à

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úso Caixa Preta (black box reuse) - Quando os ativos são inseridos ao

sistema sem qualquer modificação.

. Reúso Caixa Branca (white box reuse) - 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úso Caixa Cinza ou Cinzento (grey box reuse) – Intermediário dos dois

anteriores, quando as alterações são feitas via configuração de parâmetros.

. Reúso Transparente (glass box reuse) – 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


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


Estratégia de Implementação de um Ativo de Acordo com sua Forma

Reúso


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


Implementação de Reúso

A implementação de reúso requer:

· 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


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


• 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-on para implementar um sistema de gerenciamento de

configuração.


Reúso


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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.


Reúso


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


Ciclo de Desenvolvimento focado Domínio do Problema

Requisitos

Análise

Projeto

Construção

Aplicação

Projeto 1 Projeto 2Requisitos

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


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


29

Ciclo de Desenvolvimento focado em Reúso de 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


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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 vs Reúso:

Reúso


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


Falhas no processo...

Alguns fatores que podem ser considerados como determinantes de

fracassos no processo de implementação da cultura de reúso sã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


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


Considerações Finais:

Reúso não é uma tecnologia e sim procedimento de trabalho.

Os resultados são a médio e a longo prazo. A implementação do reúso tem

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úso de 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 Silver Bullet” (F. Brooks)

Reúso


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


RAS (Reusable Asset Specification)

RAS - Reusable Asset Specification

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 Schema and MOF XMITipos de Ativos Reusáveis de Software

Ativos


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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

combo box, 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/



Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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.



Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


Co

re R

AS

UM

L M

od

elfo

r X

ML S

ch

em

a



Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


- 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


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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 Deployment e Diagrama de Componentes.

Workflow de Design (Arquitetura):

Introdução


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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)



Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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



Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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



Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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 SistemaAnalista de Negócios

PapéisArtefatosWorkflow


Requisitos e Análise


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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 Pagamento

Enviar Fatura

Entrega durante

a noiteEntrega Regular

[pedido urgente] [senão]

Encerrar Pedido

Entrega

Especificação de Requisitos

(Visão de Caso de Uso)



Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML



48

Digrama de

Seqüência ou de

Colaboração

Diagrama de Classes

Diagrama de Atividades

Projeto

Analista de Sistema

Projetista de Software


Diagrama de Estados

Arquiteto

Design



Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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 Pagamento

Enviar Fatura

Entrega durante

a noiteEntrega 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



Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML



50

Digrama de

Componentes

Diagrama de

Deployment

Arquitetura

Analista de Sistema

Projetista de Software


Arquitetura

Arquiteto de Software

Modelo de Arquitetura



Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


Arquitetura: Road Map

Fazer DiagramasModelo de

Especificação

Documentos

de Requisitos

Caso de Uso

Fazer Modelo de

Arquitetura

Digrama de

Componentes

Digrama de

Deployment

View Controller Model Resources

JSP/HTML Servlet EJBBanco de

Dados


As principais atividades e artefatos sã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


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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



Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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




Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


processador

Elementos:

Processor (Processador): É qualquer máquina que possua a capacidade de

processamento. Os servidores, estações de trabalho por exemplo.

Dispositivo


Servidor

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



Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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


Servidor

Impressora

Cliente <<TCP/IP>>

<<RS 232>>

conexão

Dispositivo

(Nó)

Processador

(Nó)

estereotipo



Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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.


Impressora

WebBrowser

<<Cliente>>

<<RS 232>>

Apache

<<WebServer>>

<<HTTP>>

JBoss

<<Application Server>>

Oracle

<<Banco de Dados>>

Cliente

<<Client-Server>>

<<RMI>>

Nós



Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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



Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML



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

ReservaServiceReservaUI

Component

Dependência

Interface

Room



Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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



Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


Catalog

Business

Delegate

Catalog

Home

Stub

CatalogHome

Catalog

Remote

Stub

CatalogRemote

Catalog

EJB

Home

Catalog

EJB

Object

Catalog

BeanCatalogRemote

CatalogRemote

CatalogHome

Catalog.jsp

Diagrama de Componentes. Exemplo:



Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML



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 DLLs e 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



Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML



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.



Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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.



Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML




- 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



Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML




- 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



Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML




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

NewTaskSpec 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:



Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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



Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML



Todos os componentes do pacote Entities. Esses são os componentes que conterão as

classes de entidades.

Component view

As classes Entidades

Entities

Cesta

Cesta Item Produto



Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML



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

ProdutoService

Services



Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML



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

CestaInterface

Boundary



Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML



Uma visão dos componentes e relacionamentos

CestaInterfaceMainProgram

CestaService

ProdutoService

Cesta

Cesta ItemProduto



Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML



Um novo exemplo, o cenário fazer Reserva de apartamento.

ReservaUIMenu Principal

ReservaService

ClienteService

Cliente Reserva Apartamento

ApartamentoService

Model

Controller

View



Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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ão e baixo acoplamento formam 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


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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ão e

acoplamento.

Coesão e Acoplamento ajudaram na divisão de classe dentro

de componente.



Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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.



Independência

Funcional:

•Coesão e

•Acoplamento


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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



Independência

Funcional:

•Coesão e

•Acoplamento


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML



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


Tributo

- codigo

- nome

Independência

Funcional:

•Coesão e

•Acoplamento



Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


Independência

Funcional:

•Coesão e

•Acoplamento


Exemplo:

Solução é delegar a

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


Tributo

- codigo

- nome



Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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.




Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


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.




Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


81

Acoplamento


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



Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


Exemplo:

A partir do diagrama de classe, tentamos agrupar classes usando técnicas de coesão e acoplamento.




Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


Exemplo:

Temos o seguinte resultado:




Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


Exemplo 2: Digrama de Classes




Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


Exemplo 2:

A partir do diagrama de classe,

agrupar classes usando os

conceitos de coesão

e acoplamento.

Pedido

Cesta de Compra

Produto

FormaPagto




Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


Exemplo 2: Diagrama de Componentes


Cesta

Pedido

Produto

FormaPagto


Pedido

Cesta de Compra

Produto

FormaPagto


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML


Referências:

Software Reuse: Architecture, Process and Organization for Business Success

Autor Ivar Jacobson

Domain-Driven Design: Tackling Complexity in the Heart of Software

Autor Eric Evans

Managing Software Reuse

Autor Wayne C. Lim

Executable UML: A Foundation for Model-Driven Architecture

Autores: Stephen J. Mellor e Marc J. Balcer

Unified Modeling Language User Guide, The (2º. edição)

Autores: Grady Booch, James Rumbaugh e Ivar Jacobson

Component-Based Software Engineering: Putting the Pieces Together

Autores: George T. Heineman e William T. Councill

Component Software: Beyond Object-Oriented Programming (2º. Edição)

by Clemens Szyperski

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)

http://www.omg.org/uml

http://www.componentsource.com/


Dese

nh

ad

o C

om

po

ne

nte

de S

oft

ware

co

m U

ML

Todos os direitos reservados e protegidos © 2006 e 200788Arquitetura de Software

Desenhando Componentes de Software com UML®

Rildo F Santos

[email protected]

[email protected]




