Desenhando Componentes de Software com UML

Desenhado Componente de Software com UML Rildo F Santos
rildosan@uol.com.br
rildo.santos@companyweb.com.br

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

Desenhando Componentes de Software com UML®

Versão 7.0 Rildo F Santos (rildosan@uol.com.br) Arquitetura de Software
Todos os direitos reservados e protegidos © 2006 e 2007
1

Desenhado Componente de Software com UML Quem sou
Rildo 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:
Twitter: http://twitter.com/rildosan
Blog: http://rildosan.blogspot.com/

Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 2

Desenhado Componente de Software com UML 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.

Desenhado Componente de Software com UML Primeira Parte

- Introdução aos Componentes
- O que é Componentização
- Reúso de Software
- RAS (Reusable Asset Specification)


Desenhado Componente de Software com UML Componentes
Introdução

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

Versão 7.0
Todos os direitos reservados e protegidos © 2006 e 2007 5
Rildo F Santos (rildosan@uol.com.br)


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

Versão 7.0 Rildo F Santos (rildosan@uol.com.br)


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



Evolução Modelo de Componentes:



CBD
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 é parte física e substituível de um sistema que satisfaz
os requisitos de um conjunto de interfaces e fornece a sua
implementação;

O que
são componentes?



Elementos de um componentes:
Tem uma especificação
public class Item {
public Item(){
}
...
}
Tem uma
implementação

Componente

Pode ser distribuído
(“deployment”)

Aderência a
padrões

Pode ser empacotados
dentro de módulos


CBD. UML Components. Elementos de um componentes:
Especificação:
Componente 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
Tem uma especificação componente pode assumir

Possibilidade de implementações:
Componente Um componente deve suportar uma ou mais
implementações, as quais devem estar em
conformidade com a especificação.
public class Item {
A especificação deve ser flexível para que o
public Item(){ implementador possa escolher a linguagem adequada,
}
...
configuração adequada outros recursos que julgar
} necessário.
Tem uma implementação


CBD. UML Components. Elementos de um componentes:
Padrão de Componente:
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

Empacotamento:
Componente 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.

Distribuído (Deployment):
Pode ser empacotados
dentro de módulos A instalação dos componentes.
Pode ser distribuído
(“deployment”)


Principais Padrões da Industria de Componentes

Encapsulamento
CCM Corba Component Model
Coesão

Polimorfismo

Responsabilidade Componente EJB Enterprise JavaBeans

JavaBeans
Contratos

Microsoft Components
Abstração
Activex



Definição de Componentes
Benefícios:
Quais são os benefícios que são proporcionados pelo CBD ?

Temos dois tipos: Técnicos e de Negócios

Técnico Negócio
• Melhor gerenciamento da complexidade. • Melhor qualidade do produto.
(Decomposição funcional), a busca pela
• Reduz Time-to-market.
simplicidade.
• Melhor alocação de recursos humanos
• Funcionalidade complexa que não é regra de
negócio pode ser concentrada em um • Pronto para responder a mudanças
“Framework”
• Redução de custo de desenvolvimento.
• Desenvolvimento e testes em paralelo
• Habilita a capacidade de Reúso
• Baixo acoplamento
• Consistência
• Reúso



CBD. Desenvolvimento com simplicidade:


Desenhado Componente de Software com UML Reúso
Introdução:
Expectativas no desenvolvimento de Software:

Como conseguir alcançar estas expectativas ???
Existem diversas técnicas que podem ser utilizadas
para alcançar tais expectativas, entre elas está o
“Reúso...”
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.


Introdução
Como implementar o reúso sistematizado ?

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 nasceu o conceito de reúso ?
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”


Quais são os artefatos reusáveis ?
Devemos considerar que todos os artefatos que tenha um potencial de
reúso seja classificado como um Ativo Digital.

Ativo:
- Fragmentos de código de - Componentes;
programas; - Projeto e Modelo (framework e
- Documentações; designer patterns);
- Planos, estratégias e regras de - Módulos;
negócios; - Bibliotecas;
- Código Fonte, Código executável; - APIs;
- Objetos executáveis; - Descrições de domínio;
- Especificações; - Arquiteturas de software;
- Requisitos; - Diagramas
- Serviços (SOA) - Etc...


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

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.


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


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.


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


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.


Benefícios de se adotar a prática do reúso
• Simplificação do desenvolvimento de software;

• *Redução de custos, prazos de entrega e esforço para se desenvolver e
A adoção da cultura de reúso pode trazer uma série de benefícios:
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.

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.


Cenário desenvolvimento focado em Projeto
Ciclo de Desenvolvimento focado Domínio do Problema

Projeto 1 Projeto 2
Requisitos Requisitos

Análise Análise

Projeto Projeto

Construção Construção

Aplicação Reúso na maioria das Aplicação
vezes de programas ou
partes do código


Cenário desenvolvimento focado em Reúso
Ciclo de Desenvolvimento focado em Reúso de Componentes

Requisitos
Novos Projetos

Análise

Projeto
Planejamento
Construção e preparação
para reúso
Seleção
+ Produto
Modificação
Registro
Repositório

29


As camada de Domínios das classes:
Domínio da Aplicação

Domínio do Negócio

Domínio da Arquitetura

Domínio Base

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:


As camada de Domínios das classes:
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 vs Reúso:

Domínios das Classes Grau de Reusibilidade

Domínio da Aplicação Baixo reúso

Domínio do Negócio

Médio reúso

Domínio da Arquitetura

Domínio Base Alto reúso


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.


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.


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)

Desenhado Componente de Software com UML 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
Ativos
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 XMI
Tipos de Ativos Reusáveis de Software

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/


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.



Core RAS UML Model for XML Schema


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


Desenhado Componente de Software com UML Segunda Parte

- 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


Desenhado Componente de Software com UML Workflow de Design (Arquitetura):
Introdução

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.
Versão 7.0

Processo Unificado (Fases e Workflows)

Fases
Workflows Concepção Elaboração Construção Transição

Modelagem Negócios

Requisitos

Análise e Design

Implementação

Testes

Controle de Mudanças

Gerência de projeto

Ambiente
Inicial E #1 E #2 C #1 C #2 C #3 T #1 T #2


Introdução. UML, Visões:

Visão de Visão da
Projeto Implementação
Codificação
Funcionalidade Montagem
Vocabulário
Visão de
Caso de Uso
Visão do Visão da
Processo Implantação
Desempenho Topologia do Sistema
Escalabilidade Distribuição
Throughput Instalação

Conceitual Físico


Big Picture. Requisitos e Análise

Business Case Levantamento de Dados
Workflow Análise

Documento Modelo Conceitual
de Visão

Engenharia de Requisitos
Análise de Requisitos Especificação de Requisitos
(Visão de Caso de Uso) 

Requisitos Funcionais

Casos de Uso

Vocabulário de
Conceitos de Negócio
Requisitos Não
Funcionais Arquitetura Inicial

Versão 7.0

Workflow, Artefatos e Papéis: Requisitos e Análise

Workflow Artefatos Papéis
Requisitos Documento de Visão

Documento de Requisitos
Analista de Sistema
Analista de Negócios
Analista de Requisitos
Especificação de Requisitos
(Casos de Uso)

Análise
Modelo Conceitual ou Modelo
de Domínio
Analista de Sistema
Analista de Negócios
Vocabulário do Sistema


Big Picture. Design

Análise Projeto (Visão Lógica)

Modelo Conceitual Diagrama de Classes



Receber Pedido



Preencher Pedido Enviar Fatura

Entrega

[pedido urgente] [senão]

Receber Pagamento

Entrega durante Entrega Regular

Especificação de Requisitos a noite

(Visão de Caso de Uso)
: FormBusca : Categoria : Produto : Catalogo
: visitante

getDescricao( )

exibirCategoria( )

selecionarCategoria
getDescricao( ) getQuantidade( )

exibirProduto( )
Encerrar Pedido

selecionarProduto( )


Workflow, Artefatos e Papéis: Design

Projeto Digrama de
Seqüência ou de
Colaboração Analista de Sistema
Projetista de Software
Diagrama de Atividades
Arquiteto

Diagrama de Estados

Diagrama de Classes


Big Picture. Design &Arquitetura

Projeto (Visão Lógica)
Diagramas Arquitetura
Projeto (Visão de Componentes e
Visão de Deployment)



Receber Pedido

: FormBusca : Categoria : Produto : Catalogo
Preencher Pedido Enviar Fatura
: visitante

getDescricao( )

Entrega
exibirCategoria( )

selecionarCategoria [pedido urgente] [senão]
getDescricao( ) getQuantidade( )
Receber Pagamento

exibirProduto( )

Entrega durante Entrega Regular
selecionarProduto( )
a noite

Encerrar Pedido

Diagrama de Componentes
Diagrama de Deployment


Workflow, Artefatos e Papéis: Arquitetura

Arquitetura
Digrama de
Componentes
Analista de Sistema
Projetista de Software
Diagrama de Arquiteto de Software
Deployment

Modelo de Arquitetura


Arquitetura: Road Map

Digrama de
Modelo de Deployment
Especificação Fazer Diagramas
Digrama de
Componentes

Fazer Modelo de View Controller Model Resources
Documentos Arquitetura
de Requisitos
Banco de
JSP/HTML Servlet EJB
Dados

Caso de Uso

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

Arquitetura. Atividades e Passos:

Fazer Modelo Arquitetura
Selecionar uma
Arquitetura

Fazer Diagrama de Digrama de
Deployment
Deployment

Fazer Diagrama de Digrama de
Componentes Componentes

Refinar Modelo de
Arquitetura (RNFs)

Refinar o Modelo Modelo de
de Especificação Arquitetura


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.


Elementos:

Processor (Processador): É qualquer máquina que possua a capacidade de
processamento. Os servidores, estações de trabalho por exemplo.

Servidor

processador

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

Dispositivo


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

estereotipo

Servidor
Cliente <<TCP/IP>>

<<RS 232>>

Processador
Impressora (Nó)
conexão

Dispositivo
(Nó)


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.

<<WebServer>>
<<Cliente>> Apache
WebBrowser <<HTTP>>

<<RS 232>>

Impressora

Nós
<<Application Server>> <<Banco de Dados>>
JBoss Oracle

<<RMI>>

<<Client-Server>>
Cliente


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.

Dependência Componente
A

Componente
genérico

Componente Nome do
B componente


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.

ReservaService
ReservaUI

Dependência Reserva
Service_ Interface
stub
Room Component


Desenhando Componentes de Software com UML

Desenhando Componentes de Software com UML

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Desenhando Componentes de Software com UML

Similar a Desenhando Componentes de Software com UML (20)

Más de Rildo (@rildosan) Santos

Más de Rildo (@rildosan) Santos (20)

Último

Último (6)

Desenhando Componentes de Software com UML