Engenharia de Projetos

Documentos de especificacao de Projetos

- Projeto Arquitetural- Projeto de Interface- Projeto de dados- Projeto de componentes- Projeto de implantacao

PROJETO DE ARQUITETURA

Quatro passos elementares

--Representação do contexto

--Abstrações de mais alto nível através de arquétipos

--Componentes identificados e representados no contexto de arquitetura

- Instanciações especificas de arquitetura

Atividades

-Estruturacao do sistema

-Modelagem de controle

-Decomposicao modular

ESTRUTURACAO DO SISTEMA(divisao em subsistemas)

DIAGRAMA DE CASO DE USO REAL

PROJETO DE INTERFACE

DIAGRAMA DE CLASSES

ELABORANDO O DIAGRAMA DE CLASSES

Tipos-Arquitetura centrada em dados (grande fluxo de dados entre subsistemas)

-Arquitetura Cliente / Servidor (componentes: cliente, servidor, redes)

-Arquitetura em camadas ou Maquinas Abstratas

-Arquitetura de chamada e retorno

-Arquitetura orientada a objetos

Depósito de dados

Subsistema 1

Subsistema 2

Subsistema 3

Padroes Arquiteturais

-Concorrencia

-Persistencia (dados subsistem depois de criados)

-Distribuicao (ex.: uso de broker - intermediario, CORBA)

Diagrama Arquitetural de Contexto

-Subordinadores

-Subordinados

-Sistema no nivel de pares

-Atores

Modelagem de Controle

-Controle centralizado: um subsistema possui responsabilidade geral (ex. Main() )

-Controle baseado em eventos: resposta a eventos externos

Decomposicao em Modulos

-Modelo orientado a objetos

-Modelo de fluxo de dados (ex. Unix: duto e filtro)

Filtro Filtro

Filtro

Filtro

Filtro

Filtro

Filtro

Filtro

Filtro

Filtro

Arquétipos

Classe ou Padrão que representa uma abstração central critica para o projeto de arquitetura para sistema alvo. (classes abstratas, blocos construtivos, modelagem abstrata parcial)

Exercício

Desenvolva para o projeto da PETROBRAS os seguintes projetos de arquitetura:

-Tipos de Arquitetura a serem usados

-- Padrões de Arquitetura em relação a Concorrência, Persistência e Distribuição [descreva na forma de requisitos de sistema]

14

UML NO PROJETO DE COMPONENTES:1a PARTE

DIAGRAMA DE CASO DE USO REAL

PROJETO DE INTERFACE

DIAGRAMA DE CLASSES

ELABORANDO O DIAGRAMA DE CLASSES

15

I . DIAGRAMA DE CASOS DE USO REAL

Casos de uso são elaborados no levantamento de

requisitos, descrevendo o comportamento do sistema sem especifi car como esse comportamento será implementado.

16

Como exemplo, vamos considerar o caso deuso Solicita cancelamento de f atura:

Solicita cancelamento de fatura

Cliente

17

Solicita cancelamento de f atura Cenário principal: Solicitação de cancelamento integral da f atura realizada com sucesso 1. Cliente informa número da f atura 2. Sistema verifica a existência deste número 3. Sistema envia ao cliente os dados da f atura, contendo: a

data de emissão, status e valor pago 4. Cliente solicita o cancelamento integral da f atura 5. Sistema armazena a solicitação de cancelamento da f atura

e a data da solicitação 6. Sistema envia ao cliente a confi rmação do cadastramento

de sua solicitação e a informação de que o seu pedido só será analisado quando a Empresa receber os livros relativos à f atura.

18

Cenário alternativo: Solicitação já cadastrada 3. Sistema envia ao cliente os dados da f atura, contendo: a data de emissão, status, valor pago e a data em que f oi realizada a solicitação 4. Sistema comunica que a solicitação já f oi realizada Os passos seguintes não são realizados. _______________________________________________ Cenário alternativo: Fatura não encontrada 3. Sistema comunica ao cliente que não encontrou a f atura. Os passos seguintes não são realizados. _______________________________________________ Cenário alternativo: Solicitação suspensa pelo cliente ao longo do processo 4. Cliente desiste da solicitação 5. Sistema comunica que não realizou a operação. Os passos seguintes não são realizados.

19

Agora, na etapa de Projeto, devem ser descritasclasses e outros elementos que trabalharão emconjunto para a implementação do comportamento decada caso de uso.

Na UML uma colaboração permite nomear umconjunto de classes e outros elementos que trabalhamem conjunto para f ornecer algum comportamento.

Colaborações podem ser usadas para:

- especificar a realização de casos de uso- especificar a realização de operações- modelar mecanismos da arquitetura do sistema.

20

Solicita cancelamento de fatura

Cliente

Solicita cancelamento de fatura real

<<realize>>

Podemos criar um diagrama de caso de uso real,contendo casos de uso reais. Cada caso de uso real, umacolaboração, será ligado ao caso de uso elaboradodurante a análise através de uma associação comestereótipo realize.

Exemplo:

21

Como exemplo, serão apresentadas a interface e o diagrama de classes elaborados para o caso de uso Solicita cancelamento de f atura real.

Vamos ver a seguir dois elementos que podem f azer parte da descrição de um caso de uso real: a interf ace homem-máquina, o diagrama de classes e a própria especifi cação do caso de uso, referenciando a interf ace homem-máquina.

22

I I . I N T E R F A C E H - M ( e l a b o r a d a p a r a S o l i c i t aC a n c e l a m e n t o d e F a t u r a R e a l )

J a n e l a P r i n c i p a lA l t e r n a t i v a s :a ) Q u a n d o a o p ç ã o é v á l i d a

23

0

Opção inválida

b) Q uando a opção é inválida

0

24

J anelaSolicitaCancelamentoFatura

Opções:

a) Quando cadastramento realizado com sucesso

b) Quando solicitação já cadastrada

O seu pedido será analisado após o recebimento dos livros.

25

c) Quando a fatura não existir

26

A partir deste projeto de interface poderíamos elaborar a especificação do caso de uso real:

Solicita cancelamento de fatura real

Cenário principal: Solicitação de cancelamento integral da fatura realizada com sucesso

1. Sistema apresenta a JanelaSolicitaCancelamentoFatura e solicita o número da fatura

2. Cliente informa número da fatura

3. Sistema verifica a existência deste número no Banco de Dados e recupera os dados da fatura

4. Sistema apresenta os dados da fatura, contendo: a data de emissão, status e valor pago.

5. Sistema pergunta se o cliente deseja realmente realizar a solicitação.

6. Cliente solicita o cancelamento integral da fatura

7. Sistema armazena no Banco de Dados: a solicitação de cancelamento da fatura e a data da solicitação

8. Sistema apresenta na tela a confirmação do cadastramento da solicitação e a informação de que o pedido só será analisado quando a Empresa receber os livros relativos à fatura.

27

Cenário alternativo: Solicitação já cadastrada

4. Sistema apresenta os dados da fatura, contendo: a data de emissão, status, valor pago e a data em que foi realizada a solicitação.

5. Sistema comunica que a solicitação já foi realizada

Os passos seguintes não são realizados.

_______________________________________________

Cenário alternativo: Fatura não encontrada

3. Sistema verifica a inexistência deste número no Banco de Dados e apresenta uma mensagem na tela, comunicando ao cliente este fato.

Os passos seguintes não são realizados.

______________________________________________

Cenário alternativo: Solicitação suspensa pelo cliente ao longo do processo

6. Cliente desiste de solicitar o cancelamento integral da fatura

7. Sistema comunica que não realizou a operação.

Os passos seguintes não são realizados.

28

I I I . DI AGRAMA DE CLASSES (elaborado paraSolicita Cancelamento de Fatura Real)

ControladorDePedidos

obterFatura(numero : int) : Fatura_ProjcadastrarSolCancFatura(numero : int) : String

Fatura_ProjnumFatura : intdataEmissao : DatedataVencimento : DatevalorPago : doubledataPagamento : DatedataPedidoCancelamento : DatedataCancelamento : Datestatus : String

recuperarPelaPK(numFatura : int) : Fatura_ProjsolicitaCancelamento() : void

JanelaSolicitaCancelamentoFatura

exibir() : void

JanelaPrincipal

main(args : String[]) : void

29

Descrição das operações:

main - Apresenta as opções do sistema e solicita que o usuário diga oque deseja f azer. Caso ele digite uma opção inválida o usuário écomunicado. Se a opção for válida é executada a operaçãocorrespondente.

exibir - Solicita o número da f atura e verifica a existência dessenúmero através de obterFatura do ControladorDePedidos. Se afatura f or encontrada é exibida através das operações get da classeFatura_Proj . Se não for encontrada a mensagem “Fatura nãoencontrada” é exibida. Verifica se já f oi solicitado o cancelamentoanteriormente. Se tiver sido emite uma mensagem de erro. Casocontrário, pergunta se o usuário confi rma o cadastramento dasolicitação de cancelamento. Se o usuário confi rmar, a solicitação écadastrada

30

obterFatura – Obtém a f atura, através de recuperarPelaPK de Fatura. Se a f atura não f or encontrada retorna null.

cadastrarSolCancFatura – Obtém a f atura, através de

recuperarPelaPK de Fatura e caso a f atura seja encontrada chama solicitaCancelamento de Fatura e retorna a mensagem "Solicitação de cancelamento cadastrada com sucesso". Caso não seja encontrada retorna a mensagem "Fatura não encontrada". Caso a solicitação já tenha sido f eita retorna a mensagem "Solicitação cadastrada anteriormente"

solicitaCancelamento – Escreve no banco de dados a data de

solicitação e o novo status recuperarPelaPK - Busca no banco de dados os dados

relativos à f atura atribuindo-os ao objeto umaFatura

31

Obs: Cada operação poderia ser especificada de um modo mais f ormal com o diagrama de atividades, já estudado na primeira parte do curso.

32

I V. ELABORANDO O DI AGRAMA DE CLASSES

1. I dentifique todas as classes participantes da solução

No caso exemplo f oram incluídas as classes J anelaPrincipal, J anelaSolicitaCancelamentoFatura, ControladorDePedidos e Fatura_Proj .

Esta solução refl ete o f ato de se estar usando o estilo

arquitetural em camadas.

33

2. Acrescente aos atributos informações que nãoforam descritas no modelo elaborado com aperspectiva conceitual

Sintaxe completa de um atributo:

[visibilidade] nome [ [multiplicidade] ] [:tipo] [= valor inicial] [{propriedade}]

Caso o diagrama seja utilizado por uma ferramentacom geração automática de código, devem seracrescentados detalhes completos dessasinformações.

34

Visibilidade

A visibilidade de atributos pode ser pública, privadaou protegida (public, private ou protected). A seguir éapresentada a representação e o significado dessestermos:

+ public : Um atributo declarado como publicnuma classe é visível por todas as classes# protected: Um atributo declarado comoprotected numa classe é visível nas subclasses- private: Um atributo declarado como privateé visível apenas na classe na qual f oi declarado

35

No caso da ferramenta utilizada para elaborar osdiagramas deste curso a notação utilizada é diferente:

private protected public

A

xyz

36

O significado dos termos public, protected e privatepode mudar dependendo da linguagem de programação.Em J ava, por exemplo, um método ou atributo protectednuma classe pode ser acessado por subclasses mastambém por qualquer outra classe que esteja no mesmopackage.

Considerando essas dif erenças, é importante aodescrevermos a visibilidade, seguir as regras dalinguagem a ser utilizada.

37

Propriedades

Podem ser dos seguintes tipos:

- changeable: o valor do atributo pode ser modificado semrestrições

- addOnly: quando o atributo tem multiplidade maior do que um,poderão ser incluídos vários valores, mas estes não poderão serremovidos ou alterados.

- f rozen: o valor do atributo não poderá sof rer modificações umavez que o objeto tenha iniciado.

Quando não f or especificada é assumida a propriedade changeable.

Outra propriedade que pode ser incluída é:

- static: o valor de uma variável desse tipo não muda de uma classepara outra. É um valor da classe e não de um objeto em particular

38

Exemplo: dataEmissão tem visibilidade privatee é do tipo Date.

Fatura_Proj

numFatura : intdataEmissao : DatedataVencimento : DatevalorPago : doubledataPagamento : DatedataPedidoCancelamento : DatedataCancelamento : Datestatus : String

recuperarPelaPK(numFatura : int) : Fatura_Projsoli ci taCancelamento() : void

39

3. I nclua operações nas classes

Operação é um serviço que pode ser solicitado poralgum objeto da classe.

Como podemos observar no diagrama várias operaçõesforam incluídas.

Fatura_Proj

numFatura : intdataEmissao : DatedataVencimento : DatevalorPago : doubledataPagamento : DatedataPedidoCancelamento : DatedataCancelamento : Datestatus : String

recuperarPelaPK(numFatura : int) : Fatura_Projsoli ci taCancelamento() : void

40

Obs:

As operações de acesso não f oram incluídos.Operações de acesso são aquelas que obtêm (get) ouescrevem (set) o dado.

É recomendável que os atributos tenham visibilidadeprivada e que haja uma operação get e uma set para cadaatributo. Desta f orma o atributo será acessado f ora daclasse somente através de operações, possibilitando oencapsulamento. Como teríamos muitas operações get eset elas não costumam ser incluídas nos diagramas declasse.

41

4. Acrescente informações sobre os operações

A sintaxe da UML é a seguinte:

[visibilidade] nome [ (lista de parâmetros) ][:tipo-da-expressão-retornada] [{propriedade}]

42

Visibilidade

A visibilidade de operações pode ser pública,privada ou protegida. A seguir é apresentada arepresentação e o signifi cado desses termos:

+ public : Uma operação declarada comopublic numa classe é visível por todas asclasses# protected: Uma operação declarada comoprotected numa classe é visível nas subclasses- private: Uma operação declarada comoprivate é visível apenas na classe na qual f oideclarada

43

No caso da ferramenta utilizada para elaborar osdiagramas deste curso a notação utilizada é diferente:

private protected public

A

x()y()z()

44

Em Cay S. HorstMann, Gray Cornell, Core J ava –Fundamentals, vol. 1, Sun Microsystems, 1999, são feitas asseguintes considerações sobre a visibilidade em J ava:

- Os atributos de uma classe devem ser declarados comoprivate e os métodos são geralmente declarados como public.Qualquer atributo declarado como private não será visível poroutras classes e isto também vale para subclasses: umasubclasse não pode acessar os dados privados de suasuperclasse.

- Há, no entanto, situações em que se deseja que uma subclassetenha acesso a um método ou a um dado da sua classe pai.Neste caso, devemos declarar o método ou a variável comoprotected. Por exemplo, se o objeto dataContrataçao de umaclasse Empregado f osse declarado como protected em vez deprivate, então os métodos da classe Gerente (uma subclassede empregado) poderiam acessar este campo diretamente.

45

- Na prática evite utilizar atributos protected. Suponha quevocê projetou uma classe com campos protected e que estaclasse esteja sendo utilizada por outros programadores.Estes programadores poderão derivar classes a partir dasua classe e, então, poderão acessar diretamente os camposdefinidos como protected. Você não poderá mudar aimplementação da sua classe sem incomodar os outrosprogramadores. I sto é contra o espírito da programaçãoorientada a objetos, que estimula o encapsulamento.

- Métodos do tipo protected f azem mais sentido. Uma classecomplexa pode declarar um método como protected e teriacomo vantagem que só a classe e as subclasses poderiamacessar este método.

46

Parâmetros

Podem ser descritos zero ou mais parâmetros deacordo com a seguinte sintaxe:

[direção] nome: tipo [= valor-padrão]

Direção:- I n: um parâmetro de entrada que não será

modifi cado- Out: um parâmetro de saída que poderá ser

modifi cado- I nout: um parâmetro de entrada que poderá ser

modifi cado

47

Propriedade

Exemplo de uma propriedade é:

Estática – determina que a operação é da classe e nãodo objeto.

48

5 . A c r e s c e n t e a n a v e g a ç ã o

I n c l u í m o s u m a s e t a d e n a v e g a ç ã o e m u m a a s s o c i a ç ã o q u a n d od e s e j a m o s l i m i t a r a n a v e g a ç ã o a u m a ú n i c a d i r e ç ã o . S e m a s e t a d en a v e g a ç ã o a a s s o c i a ç ã o é c o n s i d e r a d a b i d i r e c i o n a l , c o m o n oe x e m p l o a s e g u i r :

Cliente

códigoCPFnomeendereçotelef one [0..1]eMail [0..1]

1..*1 f az ->

Pedido

numPedidodataEmissãonomePresenteado [0..1]endereçoEntregadataCancelamento [0..1]status

1..*1

49

E s p e c i fi c a r a d i r e ç ã o a s e r s e g u i d a n ã o s i g n i fi c an e c e s s a r i a m e n t e q u e a n a v e g a ç ã o e m u m a d a s d i r e ç õ e s éi m p o s s í v e l . A i d é i a é q u e é p o s s í v e l , p a r t i n d o - s e d e u m ae x t r e m i d a d e , c h e g a r d i r e t a e m a i s f a c i l m e n t e a o s o b j e t o s d ao u t r a e x t r e m i d a d e , i s t o p o r q u e o o b j e t o d e o r i g e m d e v ea r m a z e n a r a l g u m a r e f e r ê n c i a a o s o b j e t o s d e d e s t i n o .

N o e x e m p l o a s e g u i r , m a i s f a c i l m e n t e s e r á e n c o n t r a d o oc l i e n t e q u e f e z u m d a d o p e d i d o , m a s p o d e - s e t a m b é m c o n h e c e ro s p e d i d o s d e u m c e r t o c l i e n t e .

Cliente

códigoCPFnomeendereçotelef one [0..1]eMail [0..1]

1..*1

Pedido

numPedidodataEmissãonomePresenteado [0..1]endereçoEntregadataCancelamento [0..1]status

50

Uma associação com seta de navegação pode serinterpretada como uma visibilidade por atributo daorigem para a classe alvo.

Ao ser implementada numa linguagem orientada aobjetos, esta associação é normalmente traduzida dasseguintes f ormas, dependendo da multiplicidade:

- a classe origem terá um atributo que referenciauma instância da classe alvo

- a classe origem terá um atributo que referenciavárias instâncias da classe alvo

No exemplo anterior, a classe Pedido teria, ao serimplementada, um atributo do tipo Cliente.

51

6. Acrescente relacionamentos de dependência

Este relacionamento, apresentado através de uma setatracejada, indica que um elemento tem conhecimento deoutro elemento. A dependência é um relacionamento entredois itens em que a alteração de um item pode af etar asemântica do outro.

Num relacionamento de dependência a seta tracejadaaponta o item do qual o outro depende.

52

No diagrama de classes o relacionamento dedependência pode representar, por exemplo, que umaclasse usa outra como argumento na assinatura de umaoperação. Assim, se a classe utilizada for modificada, aoperação da outra classe pode ser af etada, pois aclasse utilizada pode, ao ser modificada, ter ainterface ou o comportamento alterado.

Uma situação deste tipo ocorre na classeControladorDePedidos: a operação ObterFaturaretorna um objeto da classe Fatura_Proj .

53

ControladorDePedidos

obterFatura(numero : i nt) : Fatura_ProjcadastrarSolCancFatura(numero : int) : String

Fatura_Proj

numFatura : intdataEmissao : DatedataVencimento : DatevalorPago : doubledataPagamento : DatedataPedidoCancelamento : DatedataCancelamento : Datestatus : String

recuperarPelaPK(numFatura : i nt) : Fatura_Projsoli ci taCancelamento() : void

54

Outro exemplo:

Exercício

Desenvolva para o projeto da PETROBRAS um caso de uso real para interface de consulta para histórico de um aluno específico.