Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
rildosan@uol.com.br
rildo.santos@companyweb.com.br
Twitter: http://twitter.com/rildosan
Blog: http://rildosan.blogspot.com/
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;
Onde estou:
Twitter: http://twitter.com/rildosan
Blog: http://rildosan.blogspot.com/
Ela é recomendada para quem atua como Arquiteto de Software e demais pessoas ligadas
ao processo de desenvolvimento 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.
Todos os direitos reservados e protegidos © 2006 e 2007
Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 3
Desenhado Componente de Software com UML Primeira Parte
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)
Desenhado Componente de Software com UML Componentes
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
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.
O que
são componentes?
Elementos de um componentes:
Tem uma especificação
public class Item {
public Item(){
}
...
}
Tem uma
implementação
Componente
Aderência a
padrões
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
Todos os direitos reservados e protegidos © 2006 e 2007
Versão 7.0 Rildo F Santos (rildosan@uol.com.br)
Desenhado Componente de Software com UML Componentes
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”)
Todos os direitos reservados e protegidos © 2006 e 2007
Versão 7.0 Rildo F Santos (rildosan@uol.com.br)
Desenhado Componente de Software com UML Componentes
Encapsulamento
CCM Corba Component Model
Coesão
Polimorfismo
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 ?
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
Introdução
Como implementar o reúso sistematizado ?
- 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.
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...
. Reúso Caixa Preta (black box reuse) - Quando os ativos são inseridos ao
sistema sem qualquer modificação.
. 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.
· 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.
• Aumento de produtividade;
• Redução de erros;
• Conhecimentos sobre sistemas e como construí-los podem ser
compartilhados;
Redução de Custos:
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.
Projeto 1 Projeto 2
Requisitos Requisitos
Análise Análise
Projeto Projeto
Construção Construção
Requisitos
Novos Projetos
Análise
Projeto
Planejamento
Construção e preparação
para reúso
Seleção
+ Produto
Modificação
Registro
Repositório
29
Domínio do Negócio
Domínio da Arquitetura
Domínio Base
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.
Domínio do Negócio
Médio reúso
Domínio da Arquitetura
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.
Especificação:
http://www.omg.org/cgi-bin/doc?formal/2005-11-02
Patrocinadores:
- IBM Rational
- LogicLibrary
- Borland
- Componentsource
Ativos
Alguns conceitos:
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.
Fonte: http://www.pfvasconcellos.eti.br/blog/2006/12/21/ativos-de-software/
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.
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
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
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
Todos os direitos reservados e protegidos © 2006 e 2007 45
Rildo F Santos (rildosan@uol.com.br)
Desenhado Componente de Software com UML Workflow de Design (Arquitetura):
Workflow, Artefatos e Papéis: Requisitos e Análise
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
Receber Pedido
Entrega
Receber Pagamento
getDescricao( )
exibirCategoria( )
selecionarCategoria
getDescricao( ) getQuantidade( )
exibirProduto( )
Encerrar Pedido
selecionarProduto( )
Diagrama de Estados
Diagrama de Classes
Receber Pedido
getDescricao( )
Entrega
exibirCategoria( )
exibirProduto( )
Encerrar Pedido
Diagrama de Componentes
Diagrama de Deployment
Modelo de Arquitetura
Digrama de
Modelo de Deployment
Especificação Fazer Diagramas
Digrama de
Componentes
Caso de Uso
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
Todos os direitos reservados e protegidos © 2006 e 2007
Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 51
Desenhado Componente de Software com UML Workflow de Design (Arquitetura):
Arquitetura. Atividades e Passos:
Refinar Modelo de
Arquitetura (RNFs)
Servidor
processador
Dispositivo
estereotipo
Servidor
Cliente <<TCP/IP>>
<<RS 232>>
Processador
Impressora (Nó)
conexão
Dispositivo
(Nó)
<<WebServer>>
<<Cliente>> Apache
WebBrowser <<HTTP>>
<<RS 232>>
Impressora
Nós
<<Application Server>> <<Banco de Dados>>
JBoss Oracle
<<RMI>>
<<Client-Server>>
Cliente
Dependência Componente
A
Componente
genérico
Componente Nome do
B componente
ReservaService
ReservaUI
Dependência Reserva
Service_ Interface
stub
Room Component
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+.
CatalogHome
CatalogHome
Catalog Catalog
Home EJB
Catalog.jsp Stub Home
Catalog
Business
Delegate
Catalog
CatalogRemote
CatalogRemote Bean
Catalog
Catalog
EJB
Remote CatalogRemote
Object
Stub
CheckIT.exe Video.dll
{versão 1.}
Disk.dll
Floppy.dll
Cliente.class
Conta.class Conta.jar
{versão 1}
Historico.class
Conta.java
NewSubprogSpec NewSubprogBody
Programa princial
(método main)
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 .exe
NewTaskSpec NewTaskBody
Componente
genérico
Interface
Component view
Boundary
Services
Entities
Component view
Cesta
Entities
As classes Entidades
Component view
CestaService
Services
ProdutoService
Component view
CestaInterface
Boundary
As classes de Interfaces
MainProgram
CestaInterface
CestaService
ProdutoService
Cesta
Produto
Cesta Item
Controller ReservaService
ClienteService
ApartamentoService
Componentes:
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.
Independência • É medida usando-se dois critérios qualitativos: coesão e
Funcional: acoplamento.
•Coesão e
•Acoplamento
Coesão: (continuação)
Coesão: (continuação)
Exemplo:
NotaFiscal Cliente
Neste exemplo é
- número - codigo
demonstrado a baixa - data emissão - nome
coesão, uma vez que a - tipo +getCodigo()
Independência classe Nota Fiscal +calcularImposto() +setCodigo()
+getNumero +getNome()
Funcional: assume a
+setNumero
•Coesão e responsabilidade de ....
fazer o cálculo dos
•Acoplamento
imposto
Coesão: (continuação)
Tributo
- codigo
- nome
Exemplo:
Acoplamento (continuação)
•Acoplamento
• Não afeta por mudanças em outros componentes
• simples de entender
• conveniente para o reúso.
Acoplamento
Relacionamento de Realização
Problema: Solução:
A classe Cliente realiza a interface iPessoa Criação de nova classe PessoaAdapter esta classe
(isto quer dizes que todos os métodos se relacionará com a interface iPessoa, desta forma
assinados na interface deve ser implementado todas as modificações ou novos implementações
na classe) Uma vez que se declare uma nova serão feitas nesta classe.
assinatura de método na interface iPessoa Desta forma reduziremos o acoplamento entre a
será necessário implementar este novo interface e a classe Cliente
método na classe Cliente.
<<interface>> <<interface>>
Realização iPessoa
iPessoa
Realização
PessoaAdapter
Cliente Herança
Cliente 81
Pedido
Cesta de Compra
Produto
FormaPagto
Produto
Pedido
Cesta de Compra
Cesta
Produto
FormaPagto
Pedido FormaPagto
www.omg.org/uml
www.componentsource.com
Twitter: http://twitter.com/rildosan
Blog: http://rildosan.blogspot.com/