Your SlideShare is downloading. ×
0
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Desenhando Componentes de Software com UML

15,410

Published on

Esta apresentação discute e fornece informações sobre o desenho de componentes de software utilizando a UML. …

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

Published in: Business, Technology
1 Comment
13 Likes
Statistics
Notes
  • Ilustre Sr. Rildo. Parabéns pelo belo material e principalmente por partilhar o mesmo na Internet
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
15,410
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
1,167
Comments
1
Likes
13
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 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
  • 2. 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/ Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 2
  • 3. 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. Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 3
  • 4. Desenhado Componente de Software com UML Primeira Parte - Introdução aos Componentes - O que é Componentização - Reúso de Software - RAS (Reusable Asset Specification) Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 4
  • 5. 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)
  • 6. Desenhado Componente de Software com UML Componentes 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....? Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br)
  • 7. 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 Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br)
  • 8. Desenhado Componente de Software com UML Componentes Evolução Modelo de Componentes: Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br)
  • 9. Desenhado Componente de Software com UML 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? Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br)
  • 10. Desenhado Componente de Software com UML 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 Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br)
  • 11. Desenhado Componente de Software com UML Componentes 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 Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br)
  • 12. Desenhado Componente de Software com UML Componentes 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”) Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br)
  • 13. Desenhado Componente de Software com UML Componentes 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 Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br)
  • 14. Desenhado Componente de Software com UML Componentes 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 Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br)
  • 15. Desenhado Componente de Software com UML Componentes CBD. Desenvolvimento com simplicidade: Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br)
  • 16. 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. Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br)
  • 17. Desenhado Componente de Software com UML Reúso 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. Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br)
  • 18. Desenhado Componente de Software com UML 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” Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br)
  • 19. Desenhado Componente de Software com UML Reúso 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... Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br)
  • 20. Desenhado Componente de Software com UML Reúso 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 Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br)
  • 21. Desenhado Componente de Software com UML Reúso 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. Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br)
  • 22. Desenhado Componente de Software com UML Reúso Estratégia de Implementação de um Ativo de Acordo com sua Forma Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br)
  • 23. Desenhado Componente de Software com UML Reúso 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. Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br)
  • 24. Desenhado Componente de Software com UML Reúso Implementação de Reúso • 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. Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br)
  • 25. Desenhado Componente de Software com UML Reúso Implementação de Reúso 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. Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br)
  • 26. Desenhado Componente de Software com UML Reúso 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. Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br)
  • 27. Desenhado Componente de Software com UML Reúso 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. Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br)
  • 28. Desenhado Componente de Software com UML Reúso 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 Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 28
  • 29. Desenhado Componente de Software com UML Reúso 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 Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br)
  • 30. Desenhado Componente de Software com UML Reúso 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: Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 30
  • 31. Desenhado Componente de Software com UML Reúso 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. Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 31
  • 32. Desenhado Componente de Software com UML Reúso 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 Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 32
  • 33. Desenhado Componente de Software com UML 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. Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br)
  • 34. Desenhado Componente de Software com UML 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. Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br)
  • 35. Desenhado Componente de Software com UML Reúso 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) Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br)
  • 36. 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 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 36
  • 37. Desenhado Componente de Software com UML RAS (Reusable Asset Specification) 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/ Versão 7.0 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 37
  • 38. Desenhado Componente de Software com UML RAS (Reusable Asset Specification) 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. Versão 7.0 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 38
  • 39. Desenhado Componente de Software com UML RAS (Reusable Asset Specification) Core RAS UML Model for XML Schema Versão 7.0 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 39
  • 40. Desenhado Componente de Software com UML Reúso 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”... Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br)
  • 41. 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 Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 41
  • 42. 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 Todos os direitos reservados e protegidos © 2006 e 2007 42 Rildo F Santos (rildosan@uol.com.br)
  • 43. Desenhado Componente de Software com UML Workflow de Design (Arquitetura): 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 Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 43
  • 44. Desenhado Componente de Software com UML Workflow de Design (Arquitetura): 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 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 44
  • 45. Desenhado Componente de Software com UML Workflow de Design (Arquitetura): 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 Todos os direitos reservados e protegidos © 2006 e 2007 45 Rildo F Santos (rildosan@uol.com.br)
  • 46. Desenhado Componente de Software com UML Workflow de Design (Arquitetura): 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 Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 46
  • 47. Desenhado Componente de Software com UML Workflow de Design (Arquitetura): 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( ) Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 47
  • 48. Desenhado Componente de Software com UML Workflow de Design (Arquitetura): Workflow, Artefatos e Papéis: Design Workflow Artefatos Papéis 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 Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 48
  • 49. Desenhado Componente de Software com UML Workflow de Design (Arquitetura): 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 Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 49
  • 50. Desenhado Componente de Software com UML Workflow de Design (Arquitetura): Workflow, Artefatos e Papéis: Arquitetura Workflow Artefatos Papéis Arquitetura Digrama de Componentes Analista de Sistema Projetista de Software Diagrama de Arquiteto de Software Deployment Modelo de Arquitetura Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 50
  • 51. Desenhado Componente de Software com UML Workflow de Design (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 Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 51
  • 52. Desenhado Componente de Software com UML Workflow de Design (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 Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 52
  • 53. Desenhado Componente de Software com UML Workflow de Design (Arquitetura): Diagrama de Deployment 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. Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 53
  • 54. Desenhado Componente de Software com UML Workflow de Design (Arquitetura): Diagrama de Deployment 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 Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 54
  • 55. Desenhado Componente de Software com UML Workflow de Design (Arquitetura): Diagrama de Deployment 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ó) Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 55
  • 56. Desenhado Componente de Software com UML Workflow de Design (Arquitetura): Diagrama de Deployment 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 Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 56
  • 57. Desenhado Componente de Software com UML Workflow de Design (Arquitetura): 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 Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 57
  • 58. Desenhado Componente de Software com UML Workflow de Design (Arquitetura): 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 Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 58
  • 59. Desenhado Componente de Software com UML Workflow de Design (Arquitetura): 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+. Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 59
  • 60. Desenhado Componente de Software com UML Workflow de Design (Arquitetura): Diagrama de Componentes. Exemplo: CatalogHome CatalogHome Catalog Catalog Home EJB Catalog.jsp Stub Home Catalog Business Delegate Catalog CatalogRemote CatalogRemote Bean Catalog Catalog EJB Remote CatalogRemote Object Stub Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 60
  • 61. Desenhado Componente de Software com UML Workflow de Design (Arquitetura): Diagrama de Componentes Tipos de Componentes: Existem três tipos de componentes: - Componentes de Implantação: São os componentes necessários para montar um sistema executável, como as 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 Video.dll {versão 1.} Disk.dll Floppy.dll Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 61
  • 62. Desenhado Componente de Software com UML Workflow de Design (Arquitetura): Diagrama de Componentes Tipos de Componentes: (continuação) - Componentes do Produto do Trabalho: Esses componentes são essencialmente o é parte do processo de desenvolvimento, formados por arquivos de código fontes, arquivos de dados, ícones. Esses componentes não fazem parte (diretamente) em sistema executável, mas são os produtos de desenvolvimento, usados para criação do sistema executável. Cliente.class Conta.class Conta.jar {versão 1} Historico.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. Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 62
  • 63. Desenhado Componente de Software com UML Workflow de Design (Arquitetura): 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. Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 63
  • 64. Desenhado Componente de Software com UML Workflow de Design (Arquitetura): Diagrama de Componentes Tipos de Componentes: - Componente: O ícone de componente representa um módulo (pedaço) de software com uma interface bem definida. Na especificação de componente definimos o estereótipo como: ActiveX, Applet, Application, DLL e EXE. Componente Nome do genérico Componente - 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 Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 64
  • 65. Desenhado Componente de Software com UML Workflow de Design (Arquitetura): Diagrama de Componentes Tipos de Componentes: - Programa Principal: Este ícone representam o programa principal. Um programa principal que contém a raiz de um programa. Na linguagem Java seria o programa que tem o método “main”. MainProgram Programa princial (método main) - Especificação e corpo do pacote: Um pacote é a implementação de uma classe. Uma especificação de pacote constitui-se em um arquivo de cabeçalho, o qual contém as informações referentes ao protótipo de função para a classe. Package Specification Package Body Um corpo de pacote pode apresentar o código para as Na linguagem C++, as operações da classe. Em C++, especificações de pacote são os os corpos de pacotes são os arquivos .h (header). Em Java arquivos usamos o ícone de especificação .cpp de pacote para representar os arquivos .java Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 65
  • 66. Desenhado Componente de Software com UML Workflow de Design (Arquitetura): 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 Além de modelar o componente propriamente dito, podemos modelar o relacionamento entre o componente e sua interface. Veja o exemplo abaixo: Componente genérico Interface Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 66
  • 67. Desenhado Componente de Software com UML Workflow de Design (Arquitetura): 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. Component view Boundary Services Entities Visão principal do Diagrama de Componentes Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 67
  • 68. Desenhado Componente de Software com UML Workflow de Design (Arquitetura): Arquitetura.Diagrama de Componentes. Exemplo: Todos os componentes do pacote Entities. Esses são os componentes que conterão as classes de entidades. Component view Cesta Entities Cesta Item Produto As classes Entidades Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 68
  • 69. Desenhado Componente de Software com UML Workflow de Design (Arquitetura): Arquitetura.Diagrama de Componentes. Exemplo: Todos os componentes do pacote Services. Esses são os componentes que conterão as classes de serviços ou de controle. Component view CestaService Services ProdutoService As classes de Serviços ou Controle Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 69
  • 70. Desenhado Componente de Software com UML Workflow de Design (Arquitetura): Arquitetura.Diagrama de Componentes. Exemplo: Todos os componentes do pacote Boundaries. Esses são os componentes que conterão as classes de Boundaries (ou de interface com usuário). Component view CestaInterface Boundary As classes de Interfaces Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 70
  • 71. Desenhado Componente de Software com UML Workflow de Design (Arquitetura): Arquitetura.Diagrama de Componentes. Exemplo: Uma visão dos componentes e relacionamentos MainProgram CestaInterface CestaService ProdutoService Cesta Produto Cesta Item Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 71
  • 72. Desenhado Componente de Software com UML Workflow de Design (Arquitetura): Arquitetura.Diagrama de Componentes. Exemplo: Um novo exemplo, o cenário fazer Reserva de apartamento. Menu Principal View ReservaUI Controller ReservaService ClienteService ApartamentoService Model Cliente Reserva Apartamento Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 72
  • 73. Desenhado Componente de Software com UML Componentes: Estudo de Caso Diagrama de Componentes. Identificação de Componentes: Componentes: Componentes são grupos de classes que representam uma funcionalidade dentro de sistema. Como faço componentes Componentes são identificados usando coesão e acoplamento. Grupos de reusáveis ? classes que exigem alta coesão e baixo acoplamento formam um componente. Como identificar os componentes ? 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. Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 73
  • 74. Desenhado Componente de Software com UML Componentes: Estudo de Caso Conceitos: Acoplamento e Coesão 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 e Acoplamento ajudaram na divisão de classe dentro de componente. Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 74
  • 75. Desenhado Componente de Software com UML Componentes: Estudo de Caso Conceitos: Acoplamento e Coesão 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 ? Independência Funcional: - Solução: Atribuir uma responsabilidade de forma que a coesão •Coesão e permaneça alta. •Acoplamento 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. Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 75
  • 76. Desenhado Componente de Software com UML Componentes: Estudo de Caso Conceitos: Acoplamento e Coesão 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; Independência - São difíceis de manter; Funcional: - São muito sensíveis a mudança; •Coesão e Classes de coesão baixa representam, geralmente, uma abstração de •Acoplamento “grande granularidade” ou atribuíram responsabilidades que deveriam ter sido delgadas a outras classes ou objetos Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 76
  • 77. Desenhado Componente de Software com UML Componentes: Estudo de Caso Conceitos: Acoplamento e Coesã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 Tributo NotaFiscalItem Produto - item[ ] - codigo - codigo - quantidade - descrição - nome +getQuantidade() +setCodigo() +setQuantidade() +getCodigo() ... Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 77
  • 78. Desenhado Componente de Software com UML Componentes: Estudo de Caso Conceitos: Acoplamento e Coesão Coesão: (continuação) Tributo - codigo - nome Exemplo: Solução é delegar a NotaFiscal responsabilidade de - número cálculo de imposto para - data emissão - tipo uma classe especializada CalculoImposto +getNumero neste assunto (usamos Independência +setNumero aqui o mecanismo de .... Funcional: delegação). Desta forma +calcularImposto() •Coesão e teremos uma alta coesão. •Acoplamento Cliente Produto NotaFiscalItem - codigo - codigo - nome - quantidade - descrição +getCodigo() +setCodigo() +getQuantidade() +setCodigo() +getCodigo() +setQuantidade() +getNome() +gerProduto ... +get/cliente() Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 78
  • 79. Desenhado Componente de Software com UML Componentes: Estudo de Caso Conceitos: Acoplamento e Coesão 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 ? Independência - Solução: Atribuir uma responsabilidade de forma que o Funcional: acoplamento permaneça fraco •Coesão e •Acoplamento 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. Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 79
  • 80. Desenhado Componente de Software com UML Componentes: Estudo de Caso Conceitos: Acoplamento e Coesão 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. Independência Funcional: •Coesão e Benefícios: •Acoplamento • Não afeta por mudanças em outros componentes • simples de entender • conveniente para o reúso. Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 80
  • 81. Desenhado Componente de Software com UML Componentes: Estudo de Caso Conceitos: Acoplamento e Coesão 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 Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br)
  • 82. Desenhado Componente de Software com UML Componentes: Estudo de Caso Diagrama de Componentes Exemplo: A partir do diagrama de classe, tentamos agrupar classes usando técnicas de coesão e acoplamento. Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 82
  • 83. Desenhado Componente de Software com UML Componentes: Estudo de Caso Diagrama de Componentes Exemplo: Temos o seguinte resultado: Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 83
  • 84. Desenhado Componente de Software com UML Componentes: Estudo de Caso Diagrama de Componentes Exemplo 2: Digrama de Classes Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 84
  • 85. Desenhado Componente de Software com UML Componentes: Estudo de Caso Diagrama de Componentes Exemplo 2: A partir do diagrama de classe, agrupar classes usando os conceitos de coesão e acoplamento. Pedido Cesta de Compra Produto FormaPagto Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 85
  • 86. Desenhado Componente de Software com UML Componentes: Estudo de Caso Diagrama de Componentes Exemplo 2: Diagrama de Componentes Produto Pedido Cesta de Compra Cesta Produto FormaPagto Pedido FormaPagto Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 86
  • 87. Desenhado Componente de Software com UML 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) Todos os direitos reservados e protegidos © 2006 e 2007 Versão 7.0 Rildo F Santos (rildosan@uol.com.br) 87
  • 88. 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 88

×