Componentes: A Abordagem Catalysis

Schubert CarvalhoThaise Yano

{schubert.carvalho,thaise.yano}@ic.unicamp.br

Universidade Estadual de Campinas - UNICAMP Instituto de Computação - IC

Disciplina de Engenharia de Software - MO409

Novembro/2004

Tópicos

Introdução e Motivação Características do Sistema Baseado em Componentes Formas de Visualização dos Componentes Componentes: Vantagens e Desvantagens Processo de desenvolvimento com Catalysis Modelos usados pela metodologia Ferramentas de Apoio Catalysis: Vantagens e Desvantagens Referências

Introdução e Motivação

Requisitos de Qualidade: manutenabilidade, portabilidade,

confiabilidade, usabilidade, interoperabilidade e reusabilidade.

Definição “Um componente de software é uma

unidade de composição com interfaces especificadas e com dependências de contexto explícitas. Um componente de software pode ser desenvolvido independentemente e está sujeito a composição de terceiros” [4].

INTERFACE

get_Qualquer_Coisa()

INTERFACE

set_Qualquer_Coisa()

Características dos Sistemas Baseados em Componentes

O desenvolvimento do software é baseado em componentes que já existem.

Fornecimento de interfaces bem definidas.

Completa separação entre interfaces e implementação.

Reutilização de especificação e projeto do componente.

O projeto baseado em Componentes é diferente do projeto OO.

Formas de Visualização dos Componentes

Componentes como implementação. Comercial Off-The-Shelf(COTS)

Componentes como abstrações arquiteturais. Catalysis:

é uma metodologia para o desenvolvimento sistemático de objetos e de sistemas baseados em componentes.

Componentes: Vantagens

Redução dos custos iniciais do sistema.

Aumento na confiança do sistema e na qualidade do software, com a reutilização de componentes que já foram bem testados e utilizados anteriormente.

O risco total no processo de desenvolvimento é reduzido se os componentes já existem.

O tempo no desenvolvimento do software pode ser reduzido.

Componentes: Desvantagens

É difícil de quantificar a redução dos custos através da reutilização de componentes.

Alguns desenvolvedores preferem reescrever o código do componente aos invés de reutilizá-lo.

Processo de Desenvolvimento

Não propõe um único processo de desenvolvimento

Propõe padrões de processo O processo de desenvolvimento pode ser

adaptado de acordo com suas características através dos padrões de processo

Três Níveis de Modelagem

Domínio do problema “Lado de fora”: descreve o ambiente no qual o sistema

está inserido Especificação do componente

“Fronteira”: descreve os comportamentos externos desejados

Projeto do componente “Lado de dentro”: descreve o projeto interno

Processo de desenvolvimento

RequisitosRequisitos

Especificação do SistemaEspecificação do Sistema

Projeto da ArquiteturaProjeto da Arquitetura

Proj. Interno do Comp.Proj. Interno do Comp.

“lado de fora”

“fronteira”

“lado de dentro”

Entendimento do problema, contextodo sistema, arquitetura e dos requisitos funcionais e não funcionaisDescrição do comportamento externo do sistema alvo usando omodelo do domínio do problemaArquitetura dos componentes e as conexões para alcançar os objetivos do projeto

Projeto das interfaces e das classespara cada componente; construçãoe teste

Processo de desenvolvimento

RequisitosRequisitos

Especificação do SistemaEspecificação do Sistema

Projeto da ArquiteturaProjeto da Arquitetura

Proj. Interno do Comp.Proj. Interno do Comp.

“lado de fora”

“fronteira”

“lado de dentro”

Requisitos

Entendimento do problema, requisitos funcionais e não funcionais, restrições arquiteturais e de planejamento

Modelos Concept Map Diagrama de contexto Cenários

Concept Map

Representação informal da estrutura dos principais termos e conceitos que são relacionados.

Ajuda a obter uma visão geral do comportamento do sistema e suas funcionalidades.

hotel apartamentos

empresário

usuárioremoto

hóspede

sistema

Diagrama de Contexto

Identifica os atores no domínio e suas interações

empresário

gerente

recepcionista

usuário remoto

hóspede

serviços deconsulta ao crédito

Emitir relatório

Controlar pagamento

Controlar ocupação

Manter cadastros

Controlar reservas

Verificar despesa

Verificardisponibilidade

usa

Cenários

Ilustra uma seqüência na qual as ações acontecemCliente Terminal

ControleCadastro Hotel

ControleReserva Reserva Quarto

Ativa sist.de controlede reserva Pedi lista

de hotéisda rede

Lista dehotéis

Mostra listade hotéis

Selecionahotel

Pedeperíodo

VerificadisponibilidadeFornece

perído

Pede listade quartos

livres

Consulta disponiblidade do quarto

Devolve disponível ou não

Lista dequartoslivres

Lista dequartoslivres

Lista dequartoslivres

Escolhequartos

Exibedados dareserva

Confirmareserva Reserva(hotel, quarto)

Numeroreserva

Reserva(hotel,quarto)

Numero reserva

Numeroreserva

Processo de desenvolvimento

RequisitosRequisitos

Especificação do SistemaEspecificação do Sistema

Projeto da ArquiteturaProjeto da Arquitetura

Proj. Interno do Comp.Proj. Interno do Comp.

“lado de fora”

“fronteira”

“lado de dentro”

Especificação do Sistema

Descreve o comportamento externo do sistema

Modelos Especificação das operações Snapshots Modelo de tipos

Especificação das Operações

Definição de pré e pós condições em termos de entrada e atributos do objeto

Operação AlteraReserva (nomeCliente, numReserva)

Pré: Existe uma reserva em nome do cliente para um determinado tipo de quarto (x) e existe a disponibilidade de outros quartos (y).

Pós: A reserva passa a ser para o tipo de quarto y. Quartos do tipo y passa a ter um quarto a menos disponível e quartos do tipo x passa ter uma quarto a mais disponível.

Snapshots

Mostram o subconjunto de valores de atributos que existem antes e depois da execução de uma operação

José da Silva

José da Silva

Reserva 30

Reserva 30 Quarto tipo A

Quarto tipo B

Quarto tipo A

Quarto tipo B

Altera Reserva

Modelos de Tipo

Sistema representado como um tipo Consiste de um modelo e um conjunto de operações

sobre esse modelo

Cliente Tipo quarto

Lista deEspera

Reserva

EfetuaReserva(numReserva, tipoQuarto, nomeCliente)CancelaReserva(numReserva, tipoQuarto, nomeCliente)AlteraReserva(numReserva, tipoQuarto, nomeCliente)ConfirmaReserva(numReserva, tipoQuarto, nomeCliente)

1 1

*

*

Processo de desenvolvimento

RequisitosRequisitos

Especificação do SistemaEspecificação do Sistema

Projeto da ArquiteturaProjeto da Arquitetura

Proj. Interno do Comp.Proj. Interno do Comp.

“lado de fora”

“fronteira”

“lado de dentro”

Projeto Arquitetural

Implementação interna do sistema Modelos

Arquitetura da aplicação Arquitetura técnica

Arquitetura Técnica

Mostra a colaboração entre componentes de tecnologia e as dependências estáticas

BD

BD

UIServidor

da aplicação

Arquitetura da Aplicação

Implementa a lógica do negócio como uma coleção de componentes que se colaboram

BD

BD

UI

Servidor da Aplicação

Processo de desenvolvimento

RequisitosRequisitos

Especificação do SistemaEspecificação do Sistema

Projeto da ArquiteturaProjeto da Arquitetura

Proj. Interno do Comp.Proj. Interno do Comp.

“lado de fora”

“fronteira”

“lado de dentro”

Implementação do Componente

Estrutura interna e interações do componente

Modelos Diagrama de interação Diagrama de classes Diagrama de estados

Diagrama de Interação

Especifica como os objetos interagem com outros para atingir o resultado de uma operação

Reserva Lista de Espera

Atualizanumero de

quartos

Existe lista?

sim

Insere cliente na lista

Remove da lista

Diagrama de Classe

Classes que compõe o sistema, seus atributos, operações e associações

+EfetuaReserva()+CancelaReserva()+AlteraReserva()+ConfirmaReserva()

-numReserva-nomeCliente-tipoQuarto-período

Reserva

+InsereCliente()+RemoveCliente()+AlteraCliente()

-nomeCliente-endereço-telefone-motivoViagem-e-mail

Cliente

-qtdeQuartos-tipoMobília

Quarto

+CriaLista()+RemoveLista()+InsereNaLista()+RemoveDaLista()

-períodoLista-nomeCliente

ListaEspera

**

possui

*

*

* 1

faz

contém

Diagrama de Estados

Representa os estados de uma classe

Inexistente Efetuada

Confirmada

Existente

EfetuaReserva

CancelaReserva

ConfirmaReserva

data atual >data reserva

Ferramentas de Apoio

Ferramentas de apoio à modelagem UML Rational Rose ArgoUML Visual Paradigm

Desvantagens

Não provê um modo pré-definido do processo de desenvolvimento

Não há recurso para teste

Vantagens

Desenvolvimento flexível Centrada em UML Mapeamento para implementação Coerência

Referências

[1] Pressman, R.S. Software Engineering – A practitioner´s approach. McGraw-Hill, 5ª edition, 2001.

[2] Brown A.W., The Current State of CBSE. IEEE, 1998. [3] Sommerville I. Software Engineering. Addison Wesley. 5ª edition, 1996. [4] Szypersky, C. Component Software: Beyond Object-Oriented Programming. Addison-Wesley

Publishing Company, ACM Press, New York 1998. [5] Booch G., Rumbaugh J. & Jacobson I.. The Unified Modeling Language User Guide. Addsion-

Wesley, 1999. [6]Flanagan D. Java in a Nutshell. A Desktop Quick Reference. O´REILLY. , 3ª edition, 1999. [7] Boertien N., Steen M.W.A., Jonkers H.. Evaluation of Component-Based Development Methods [8] D´Souza D.F., Wills A.C. Objects, Components, and Frameworks with UML. The Catalysis

Approach. Addsion-Wesley. 1999.