Especificação de Componentes
8° SI -‐ UMC
Prof. Fabiano
Um pouco de história…
“Crise do So8ware“, expressa o estado de arte
da produção de so8ware entre os anos 80 e
início dos anos 90.
Época em que crescia as demandas de so8ware,
desejo de automaIzar para agilizar o negócio,
gerar oportunidades e diminuir custos
operacionais.
Um pouco de história…
Problemas: má qualidade, baixa produIvidade,
alto custo, complexidade de manutenção.
Na década de 80, surge o paradigma de
orientação à objetos que fortaleceu a
possibilidade de reu>lização.
Com a necessidade de construir so8ware de
forma rápida e com qualidade, no final dos anos
90 surgiu a proposta de desenvolvimento
reu>lizando componentes.
Reuso de SoEware
PráIca sistemáIca de desenvolver ou atualizar
novas aplicações a parIr de “a>vos de
soEware” pré-‐construídos nos quais são
idenIficados similaridades de requisitos e/ou
arquiteturas com o que está sendo
Reuso de SoEware
Todos os artefatos que tenha um potencial de
reuso é classificado como um A>vo Digital.
-‐ O Que pode ser um aIvo digital?
Fragmentos de código de programas; Documentações;
Planos, estratégias e regras de negócios; Código Fonte,
Código executável; Objetos executáveis; Especificações;
Requisitos; Serviços (SOA); Componentes; Projeto e Modelo
(framework e designer paderns); Módulos; Bibliotecas;
APIs; Descrições de domínio; Arquiteturas de so8ware;
Diagramas, etc...
Reuso de SoEware
Por que reusar so8ware?
Há 60 anos atrás não havia so8ware.
Hoje há mais de 100 bilhões de linhas de código em
bibliotecas de funções para diversas áreas
especificadas.
“Seu problema” já pode ter sido resolvido por
alguém antes.
Reuso de SoEware
Como implementar o Reuso de so1ware?
Três ações são necessárias para a implementação:
-‐ Planejamento:
Planejamento refere-‐se à compreensão de como o reuso pode contribuir para se a>ngir os obje>vos da organização como um todo;
-‐ Disciplina:
Definição de medidas para mensurar e controlar o sucesso do reuso e ao estabelecimento de suporte organizacional,
técnico e orçamentário apropriados.
-‐ Envolvimento:
Preparação, treinamento e ferramentas, dos profissionais envolvidos para executar o reuso.
Reuso de SoEware
A implementação de reuso requer:
1) 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 a>vos. O gerenciamento de projeto
também sofre impacto, assim como aspectos de cronograma,
custos e produ>vidade.
2) Adição de Processos de Reuso:
Análise de domínio pode ou não ser usada para direcionar a idenIficação de aIvos reusáveis. AIvos podem ser menores ou maiores, incluindo ou não projeto e requisitos. Podem ser produzidos e manIdos por um grupo específico ou por
projeto, antes de serem necessários ou no momento que forem requisitados pela primeira vez.
Reuso de SoEware
A implementação de reuso requer:
3) Trabalhar fatores humanos:
Criar uma polí>ca de incen>vos. Uma ou mais técnicas podem ser usadas, como treinamento, eventos de
conscien>zação, grupos de discussões, etc.
4) Instalação de repositório:
Definir a políIca 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 para implementar um sistema de gerenciamento de configuração.
Reuso de SoEware
Para administrar de forma eficiente um
Repositório, ter procedimentos para:
-‐ Gerenciamento de versões: mecanismo para
controlar essas versões e estabelecer o
relacionamento entre elas.
-‐ Gerência de Controle e Mudanças: procedimentos
para solicitação de alterações, discussões e
Reuso de SoEware
Reuso de SoEware
Cenário desenvolvimento focado em Reuso
Reuso de SoEware
Uma aplicação que segue a orientação a objetos
conterá classes de quatro principais domínios:
Reuso de SoEware
• 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 Ipo 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 disposiIvos.
• 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 Ipos de dados, coleções e etc. Geralmente estas classes estão atrelados a linguagem de programação.
Reuso de SoEware
Reuso de SoEware
Classificação das Formas de Reuso
Quando um artefato é reusado, pode-‐se
classificar esse reuso 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
Reuso de SoEware
Classificação de Reuso
•
Reuso Caixa Preta: Quando os aIvos são inseridos ao
sistema sem qualquer modificação.
•
Reuso Caixa Branca: Quando há necessidade de
reengenharia, ou seja, quando for necessário a
modificação do corpo do aIvo para se obter as
Reuso de SoEware
Classificação de Reuso
•
Reuso Caixa Cinza ou Cinzento: Intermediário dos
dois anteriores, quando as alterações são feitas via
configuração de parâmetros.
•
Reuso Transparente: Em situações nas quais não se
faz necessário fazer alterações, mas para descobrir
as propriedades do aIvo é preciso olhar dentro dele,
pois a descrição disponível não traz informações
Reuso de SoEware
Bene[cios de se adotar a prá>ca do reuso
§
Simplificação do desenvolvimento de
so8ware;
§
Redução de custos, prazos de entrega e
esforço para se desenvolver e manter o
so8ware;
§
Aumento de produIvidade;
§
Desenvolvimento de so8ware de maior
qualidade, e portanto, de maior
Reuso de SoEware
Bene[cios de se adotar a prá>ca do reuso
§
Redução de erros;
§
Conhecimentos sobre sistemas e como
construí-‐los podem ser comparIlhados;
§
Facilidade em aprender sobre arquiteturas de
sistemas
§
ComparIlhamento de conhecimentos
adquiridos com a experiência, ou seja,
comparIlhamento das melhores práIcas.
Reuso de SoEware
Falhas no processo:
• Não envolvimento e compromeImento 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 reuso, como análise de requisitos, de projeto;
• Nenhuma preocupação ou direcionamento para fatores humanos, como treinamento e moIvação e
• Entendimento da empresa que repositório ou tecnologia orientada a objetos tratados isoladamente, sem ações complementares, significam reuso.
Conceito de Orientação a Objeto
q
Vantagens de Orientação a Objeto
•
Facilita a reuIlização de código;
•
Os modelos refletem o mundo real de maneira
mais aproximada:
–
Descrevem de maneira mais precisa os dados;
–
Mais fáceis de entender e manter.
•
Pequenas mudanças nos requisitos não
implicam em alterações massivas no sistema
em desenvolvimento.
Conceito de Orientação a Objeto
Orientação a Objeto => classificar , organizar e
abstrair coisas
Significa organizar o mundo real como uma
coleção de objetos que incorporam estrutura
de dados e um conjunto de operações que
Conceito de Orientação a Objeto
Domínio: uma casa
Olhando para a estante, o guarda-‐roupa, o
armário, a cozinha. Em todos estes lugares
podemos classificar coisas baseado em alguma
concepção que possuímos sobre elas.
No contexto orientado a objeto a estante , o
armário , a cozinha são chamados de classes.
Conceito de Orientação a Objeto
No contexto de so8ware podemos dizer que
uma classe:
§
é um gabarito para a definição de objetos.
Através da definição de uma classe, descreve-‐
se que propriedades -‐-‐ ou atributos -‐-‐ o objeto
terá.
§
mantém dois elementos
importantes : estrutura e comportamento.
–
Uma estrutura representa os atributos que
descrevem a classe.
–
Um comportamento representa os serviços que a
classe suporta.
Conceito de Orientação a Objeto
Conceitos básicos vinculados a orientação a
objetos:
•
Herança
•
Encapsulamento
•
Polimorfismo
Conceito de Orientação a Objeto
Herança
mecanismo que permite que caracterís>cas
comuns a diversas classes sejam agrupadas em
uma classe base, ou superclasse.
Pensemos na classe carro.
Esta classe define os comportamentos e atributos de um carro; E existem atributos que serão comum a todos os carros.
As rodas e o motor são atributos comuns a qualquer carro. Já uma Ferrari possui atributos que somente ela possui: o preço,
Conceito de Orientação a Objeto
Encapsulamento
Encapsular significa "ocultar informações”, ele define que
cada objeto contém todos os detalhes de implementação
(dados e objetos) necessários sobre como ele funciona e
oculta os detalhes internos sobre como ele executa os
serviços.
Quando você acelera um carro você esta enviando uma mensagem ao motor do carro usando o acelerador e o carro
sabe que tem que acelerar.
Você não precisa saber como é feita a aceleração no motor você apenas pisa fundo no acelerador, a implementação de como é
Conceito de Orientação a Objeto
Polimorfismo
é o princípio pelo qual duas ou mais classes derivadas
de uma mesma superclasse podem invocar métodos
que têm a mesma iden>ficação (assinatura) mas
comportamentos dis>ntos, especializados para cada
classe derivada, usando para tanto uma referência a
um objeto do Ipo da superclasse."
Componentes
Componente é um bloco construIvo modular
para so8ware de computador.
“... Uma parte modular, possível de ser
implantada e subs>tuível de um sistema que
encapsula implementação e expõe um conjunto
de interfaces”.
Componentes
Princípio da divisão e conquista
dividir um grande problema em partes menores
e resolver essas partes menores
Componentes
Dividir para conquistar é um conceito u>lizado
desde que a programação estruturada foi criada.
A programação estruturada usava a idéia de dividir
para conquistar na forma de decomposição
funcional. Porém, os dados relacionados a essas
funções não recebiam o mesmo tratamento. Eles
eram manIdos em grandes bases, responsáveis por
dados relacionados a diversas funcionalidades.
Dessa forma o reuso e a gerência de mudanças
ficavam extremamente comprome>dos. Com isso,
não só as funções eram bastante dependentes
Componentes
A orientação a objetos tratou de minimizar o
problema da dependência com a uIlização de
classes para unir funções e dados correlatos.
Um componente de negócio aglomera um
conjunto de classes e dados altamente
relacionados, em uma mesma unidade.
Componentes
Estamos falando de modularização
O principal problema quanto aos sistemas de so8ware é
a complexidade — não o número de classes ou linhas de
código em si, mas seu interrelacionamento.
Uma ação muito boa contra a complexidade é a
decomposição do problema de modo que o resultado
apresente as caracterís>cas de pequenos programas.
A modularização efe>va é alcançada maximizando a
coesão e minimizando o acoplamento. Esse princípio
ajuda a decompor tarefas complexas em tarefas mais
simples.
Componentes
É enorme a possibilidade de encontrarmos
funcionalidades redundantes entre as várias
aplicações existentes em uma empresa.
Arquiteturas baseadas em componentes de negócio
oferecem uma maior capacidade de reuso.
O maior obje>vo a ser alcançado quando se projeta
um componente de negócio é aIngir um alto nível
Componentes
Por exemplo:
Sempre que a lógica de um determinado processo de
negócio informaIzado sofre uma modificação, a
estrutura de so8ware responsável por manter essa lógica
deverá, por consequência, ser modificada também.
Se toda essa lógica for projetada em forma de
componentes de negócio, com suas dependências bem
formuladas e delimitadas, a troca de um componente por
outro ou a modificação de regras internas de um
componente é bem menos traumáIca do que a
manutenção tradicional em sistemas não
Componentes
Isso só é possível porque um componente só se comunica
através de suas interfaces. As interfaces de um componente representam a especificação daquilo que ele se propõe a
oferecer.
O desenvolvimento baseado em componentes se destaca das outras abordagens existentes justamente por separar a
interface de sua implementação.
Como os componentes só se comunicam por meio de suas interfaces, suas implementações ficam isoladas, o que reduz
Componentes
Observe que a classe ClienteExistente não precisou sofrer
qualquer Ipo de modifi cação para suportar o novo
Iden>ficando Componentes
No processo de arquitetura, os componentes são
desenhados da seguinte forma:
• Diagrama de Classes é revisado e grupos de classes
com independência funcional são idenIficados usando
as técnicas de coesão (alta coesão) e acoplamento
(baixo acoplamento).
• Este grupos irão representar os componentes.
Independência Funcional: Conceito que está diretamente
relacionado a modularidade, abstração e
encapsulamento de informação (divisão em partes
menores).
Iden>ficando Componentes
Principais caracterísIcas:
•
função de propósito único.
•
Interfaces simples quando visto de outras
partes da estrutura do programa.
•
É medida usando-‐se dois critérios qualitaIvos:
coesão e acoplamento.
Componentes
Exercício
Exercício -‐ Resposta
Resposta:
Cesta de Compra
Produto Pedido
Forma de Pagamento
Exercício -‐ Resposta
Diagrama de Componentes
Cesta de Compra
Produto Pedido
Forma de Pagamento
Projeto de Componentes
Um conjunto completo de componentes de
so8ware é definido durante o projeto da
arquitetura. Porém, os detalhes de processamento
e estruturas de dados internas de cada
componente não são representados em um nível
de abstração próximo ao código.
O projeto de componentes define as estruturas de
dados, os algoritmos, as caracterís>cas das
interfaces e os mecanismos de comunicação
alocados a cada componente de so8ware.
Um engenheiro de soEware realiza o projeto de
componentes.
Projeto de Componentes
Por que é importante?
§
Você̂ deve ser capaz de determinar se o so8ware
irá funcionar ou não antes de construí́-‐lo.
§
projeto de componentes representa o so8ware
de maneira que lhe permita revisar os detalhes
do projeto em termos de correção e consistência
com outras representações de projeto (isto é, os
projetos de interfaces, arquitetura e dados).
§
Fornece um meio para avaliar se as estruturas de
dados, interfaces e algoritmos vão funcionar.
Projeto de Componentes
Etapas Envolvidas
§ As representações de projeto de dados, arquitetura e
interfaces formam a base para o projeto de componentes. § A definição de classes ou a narraIva de processamento para
cada um dos componentes é traduzida em um projeto
detalhado que faz uso de formas esquemáIcas ou baseadas em texto que especificam estruturas de dados internas,
detalhes de interfaces locais e lógica de processamento. § A notação de projeto engloba diagramas UML e
representações complementares.
§ Normalmente é possível adquirirem-‐se componentes de so8ware reuIlizáveis em vez de construir novos
Projeto de Componentes
As principais aIvidades e artefatos são:
•
A>vidades: IdenIficar componentes, fazer
Diagrama de Componentes, representar os
componentes no Diagrama de Deployment.
•
Artefatos: Diagrama de Componentes e
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. § Diagrama de componente descreve os componentes de
so8ware e suas dependências entre si, representando a estrutura do código gerado. Eles são Ipicamente os
arquivos implementados no ambiente de desenvolvimento. § Diagrama de componente representa uma visão |sica, é um
pedaço de so8ware 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.
Diagrama de Componentes
Na UML há 3 Ipos diferentes de componentes, os quais são:
De execução, que existem enquanto a aplicação está em tempo de
execução, como os processos e threads, entre outros.
De instalação, que são geralmente arquivos executáveis, controles
AcIve-‐X (ferramenta da Microso8 para rodar qualquer componente de so8ware nos navegadores independente da linguagem de
programação em que foram feitos), DLLs (arquivo executável que atua como uma biblioteca dinâmica comparIlhada de funções, uIlizada para rodar aplicações corretamente, também serve para os
programadores adicionarem as funcionalidades desejadas em seus códigos fontes) etc.
De trabalho, que são aqueles que dão origem aos componentes de
Diagrama de Componentes
E a UML reconhece 5 estereóIpos (definições, especificações) para estes componentes, que são:
§ Executável, que é um componente que pode ser executado como
um so8ware, programa (.jar, .exe,entre outras extensões possíveis).
§ Biblioteca, que pode ser de classes e/ou funções, estáIca ou
dinâmica.
§ Tabela, que é como uma tabela de banco de dados.
§ Documento, que é uma parte da documentação do projeto, pode
incluir texto livre, diagramas,documentos de ajuda, entre outros. § Arquivos, que são outros Ipos de arquivos, geralmente, tratam-‐se
de códigos-‐fonte, mas também pode incluir arquivos de dados, um “script” ou outros esIlos de arquivos.
Diagrama de Componentes
Notação de componente na UML.
As “portas” representadas em volta de um componente,
são métodos que são disponibilizados por interfaces e
classes de um componente e que estão disponível para
outros componentes ou so8ware, ou são métodos que
classes deste componente invoca de outro componente.
Diagrama de Componentes
Uma outra forma de representar a dependência entre os componentes é através de setas.
Diagrama de Deployment
§
Os diagramas de deployment representam a
estrutura [sica (normalmente de hardware),
onde um conjunto de artefatos de so8ware são
instalados para compor uma configuração de um
sistema.
§
Essa estrutura |sica é consItuída por nós,
conectados por vias de comunicação.
§
Nós podem representar tanto disposiIvos de
hardware como ambientes de execução de
so8ware (servidor). Artefatos representam
elementos concretos do mundo |sico, resultados
de um processo de desenvolvimento.
Diagrama de Deployment
Artefato
§ Um artefato é a especificação de um conjunto concreto de informações que é uIlizado ou produzido por um processo de desenvolvimento de so8ware, ou para a instalação ou operação de um sistema computacional. Exemplos de
artefatos incluem arquivos de modelos, arquivos de código-‐ fonte, scripts, arquivos executáveis, tabelas em bancos de dados, documento de texto, mensagem de e-‐mail ou
qualquer outro resultado de um processo de desenvolvimento.
§ Um artefato representa, portanto, um elemento concreto do mundo |sico. Uma instância par>cular do artefato (ou
Diagrama de Deployment
Artefato
Na linguagem UML, um artefato é apresentado uIlizando-‐se o retângulo de uma classe ordinária, com o uso da palavra-‐chave «arIfact».
AlternaIvamente, este retângulo pode acrescentar ainda um pequeno ícone no canto superior direito do retângulo.
Ao lado um exemplo mostrando como pode-‐se detalhar a consItuição de um artefato (por meio de componentes), uIlizando-‐se de relações de dependência estereoIpadas.
Diagrama de Deployment
Nós
§ Recurso computacional onde artefatos podem ser instalados para
posterior execução. Nós podem ser interconectados por meio de conexões que definem estruturas de redes.
§ Estas conexões representam caminhos de comunicação possíveis entre
os nós. Topologias específicas de redes podem ser definidas por meio dessas conexões. Nós hierárquicos (ou seja, nós dentro de nós) podem ser definidos uIlizando-‐se associações do Ipo composição, ou
definindo-‐se uma estrutura interna para aplicações de modelagem avançada.
§ Arcos tracejados com o uso do keyword «deploy» podem ser uIlizados
para representar a capacidade de um nó de suportar um determinado Ipo de artefato. AlternaIvamente, isso pode ser representado
uIlizando-‐se artefatos aninhados dentro do nó. Em ambos os casos, isso significa que o artefato correspondente encontra-‐se instalado no nó.
Diagrama de Deployment
Nós
Notação
Diagrama de Deployment
Nós
