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

-Representao do contexto -Abstraes de mais alto nvel atravs de arqutipos

-Componentes identificados e representados no contexto de arquitetura

-

- Instanciaes 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)
-

Subsistema 2 Subsistema 1 Subsistema 3

Depsito de dados

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

-

Arquitetura em camadas ou Maquinas Abstratas Arquitetura de chamada e retorno Arquitetura orientada a objetos

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

Arqutipos
Classe ou Padro que representa uma abstrao central critica para o projeto de arquitetura para sistema alvo. (classes abstratas, blocos construtivos, modelagem abstrata parcial)

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

Tipos de Arquitetura a serem usados

- Padres de Arquitetura em relao a Concorrncia, Persistncia e Distribuio [descreva na forma de requisitos de sistema]
-

UML NO PROJETO DE COMPONENTES: 1a PARTE

DIAGRAMA DE CASO DE USO REAL

PROJETO DE INTERFACE
DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES

14

I. DIAGRAMA DE CASOS DE USO REAL

Casos de uso so elaborados no levantamento de requisitos, descrevendo o comportamento do sistema sem especificar como esse comportamento ser implementado.

15

Como exemplo, vamos considerar o caso de uso Solicita cancelamento de fatura:

Cliente Solicita cancelamento de fatura

16

Solicita cancelamento de fatura

Cenrio principal: Solicitao de cancelamento integral da fatura realizada com sucesso

1. Cliente informa nmero da fatura 2. Sistema verifica a existncia deste nmero 3. Sistema envia ao cliente os dados da fatura, contendo: a data de emisso, status e valor pago 4. Cliente solicita o cancelamento integral da fatura 5. Sistema armazena a solicitao de cancelamento da fatura e a data da solicitao 6. Sistema envia ao cliente a confirmao do cadastramento de sua solicitao e a informao de que o seu pedido s ser analisado quando a Empresa receber os livros relativos fatura.

17

Cenrio alternativo: Solicitao j cadastrada

3. Sistema envia ao cliente os dados da fatura, contendo: a data de emisso, status, valor pago e a data em que foi realizada a solicitao 4. Sistema comunica que a solicitao j foi realizada Os passos seguintes no so realizados.

_______________________________________________ Cenrio alternativo: Fatura no encontrada

3. Sistema comunica ao cliente que no encontrou a fatura.

Os passos seguintes no so realizados.

_______________________________________________ Cenrio alternativo: Solicitao suspensa pelo cliente ao longo do processo

4. 5. Cliente desiste da solicitao Sistema comunica que no realizou a operao.

Os passos seguintes no so realizados.

18

Agora, na etapa de Projeto, devem ser descritas classes e outros elementos que trabalharo em conjunto para a implementao do comportamento de cada caso de uso. Na UML uma colaborao permite nomear um conjunto de classes e outros elementos que trabalham em conjunto para fornecer algum comportamento. Colaboraes podem ser usadas para: - especificar a realizao de casos de uso - especificar a realizao de operaes - modelar mecanismos da arquitetura do sistema.

19

Podemos criar um diagrama de caso de uso real, contendo casos de uso reais. Cada caso de uso real, uma colaborao, ser ligado ao caso de uso elaborado durante a anlise atravs de uma associao com esteretipo realize. Exemplo:
Cliente Solicita cancelamento de fatura <<realize>>

Solicita cancelamento de fatura real

20

Vamos ver a seguir dois elementos que podem fazer parte da descrio de um caso de uso real: a interface homem-mquina, o diagrama de classes e a prpria especificao do caso de uso, referenciando a interface homem-mquina.
Como exemplo, sero apresentadas a interface e o diagrama de classes elaborados para o caso de uso Solicita cancelamento de fatura real.

21

II. INTERFACE H-M (elaborada Cancelamento de Fatura Real)

JanelaPrincipal Alternativas: a) Quando a opo vlida

para Solicita

22

b) Quando a opo invlida

0 Opo invlida

23

JanelaSolicitaCancelamentoFatura Opes: a) Quando cadastramento realizado com sucesso

O seu pedido ser analisado aps o recebimento dos livros.

b) Quando solicitao j cadastrada

24

c) Quando a fatura no existir

25

A partir deste projeto de interface poderamos elaborar a especificao do caso de uso real:
Solicita cancelamento de fatura real
Cenrio principal: Solicitao de cancelamento integral da fatura realizada com sucesso 1. Sistema apresenta a JanelaSolicitaCancelamentoFatura e solicita o nmero da fatura 2. Cliente informa nmero da fatura 3. Sistema verifica a existncia deste nmero no Banco de Dados e recupera os dados da fatura 4. Sistema apresenta os dados da fatura, contendo: a data de emisso, status e valor pago. 5. Sistema pergunta se o cliente deseja realmente realizar a solicitao. 6. Cliente solicita o cancelamento integral da fatura 7. Sistema armazena no Banco de Dados: a solicitao de cancelamento da fatura e a data da solicitao 8. Sistema apresenta na tela a confirmao do cadastramento da solicitao e a informao de que o pedido s ser analisado quando a Empresa receber os livros relativos fatura.
26

Cenrio alternativo: Solicitao j cadastrada 4. Sistema apresenta os dados da fatura, contendo: a data de emisso, status, valor pago e a data em que foi realizada a solicitao. 5. Sistema comunica que a solicitao j foi realizada Os passos seguintes no so realizados. _______________________________________________ Cenrio alternativo: Fatura no encontrada

3. Sistema verifica a inexistncia deste nmero no Banco de Dados e apresenta uma mensagem na tela, comunicando ao cliente este fato.
Os passos seguintes no so realizados. ______________________________________________ Cenrio alternativo: Solicitao suspensa pelo cliente ao longo do processo

6. Cliente desiste de solicitar o cancelamento integral da fatura

7. Sistema comunica que no realizou a operao. Os passos seguintes no so realizados.

27

III. DIAGRAMA DE CLASSES (elaborado para Solicita Cancelamento de Fatura Real)

Fatura_Proj numFatura : int dataEmissao : Date dataVencimento : Date valorPago : double dataPagamento : Date dataPedidoCancelamento : Date dataCancelamento : Date status : String recuperarPelaPK(numFatura : int) : Fatura_Proj solicitaCancelamento() : void

ControladorDePedidos obterFatura(numero : int) : Fatura_Proj cadastrarSolCancFatura(numero : int) : String JanelaSolicitaCancelamentoFatura exibir() : void

JanelaPrincipal main(args : String[]) : void

28

Descrio das operaes:

main - Apresenta as opes do sistema e solicita que o usurio diga o que deseja fazer. Caso ele digite uma opo invlida o usurio comunicado. Se a opo for vlida executada a operao correspondente. exibir - Solicita o nmero da fatura e verifica a existncia desse nmero atravs de obterFatura do ControladorDePedidos. Se a fatura for encontrada exibida atravs das operaes get da classe Fatura_Proj. Se no for encontrada a mensagem Fatura no encontrada exibida. Verifica se j foi solicitado o cancelamento anteriormente. Se tiver sido emite uma mensagem de erro. Caso contrrio, pergunta se o usurio confirma o cadastramento da solicitao de cancelamento. Se o usurio confirmar, a solicitao cadastrada

29

 obterFatura Obtm a fatura, atravs de recuperarPelaPK de Fatura. Se a fatura no for encontrada retorna null. cadastrarSolCancFatura Obtm a fatura, atravs de recuperarPelaPK de Fatura e caso a fatura seja encontrada chama solicitaCancelamento de Fatura e retorna a mensagem "Solicitao de cancelamento cadastrada com sucesso". Caso no seja encontrada retorna a mensagem "Fatura no encontrada". Caso a solicitao j tenha sido feita retorna a mensagem "Solicitao cadastrada anteriormente" solicitaCancelamento Escreve no banco de dados a data de solicitao e o novo status recuperarPelaPK - Busca no banco de dados os dados relativos fatura atribuindo-os ao objeto umaFatura

30

Obs: Cada operao poderia ser especificada de um modo mais formal com o diagrama de atividades, j estudado na primeira parte do curso.

31

IV. ELABORANDO O DIAGRAMA DE CLASSES

1. Identifique todas as classes participantes da soluo No caso exemplo foram includas as classes JanelaPrincipal, JanelaSolicitaCancelamentoFatura, ControladorDePedidos e Fatura_Proj.

Esta soluo reflete o fato de se estar usando o estilo arquitetural em camadas.

32

2. Acrescente aos atributos informaes que no foram descritas no modelo elaborado com a perspectiva conceitual Sintaxe completa de um atributo: [visibilidade] nome [ [multiplicidade] ] [:tipo] [= valor inicial] [{propriedade}]
Caso o diagrama seja utilizado por uma ferramenta com gerao automtica de cdigo, devem ser acrescentados detalhes completos dessas informaes.

33

 Visibilidade A visibilidade de atributos pode ser pblica, privada ou protegida (public, private ou protected). A seguir apresentada a representao e o significado desses termos: + public : Um atributo declarado como public numa classe visvel por todas as classes # protected: Um atributo declarado como protected numa classe visvel nas subclasses private: Um atributo declarado como private visvel apenas na classe na qual foi declarado

34

35

O significado dos termos public, protected e private pode mudar dependendo da linguagem de programao. Em Java, por exemplo, um mtodo ou atributo protected numa classe pode ser acessado por subclasses mas tambm por qualquer outra classe que esteja no mesmo package. Considerando essas diferenas, importante ao descrevermos a visibilidade, seguir as regras da linguagem a ser utilizada.

36

 Propriedades Podem ser dos seguintes tipos: - changeable: o valor do atributo pode ser modificado sem restries - addOnly: quando o atributo tem multiplidade maior do que um, podero ser includos vrios valores, mas estes no podero ser removidos ou alterados. - frozen: o valor do atributo no poder sofrer modificaes uma vez que o objeto tenha iniciado. Quando no for especificada assumida a propriedade changeable. Outra propriedade que pode ser includa : - static: o valor de uma varivel desse tipo no muda de uma classe para outra. um valor da classe e no de um objeto em particular
37

Exemplo: dataEmisso tem visibilidade private e do tipo Date.

38

3. Inclua operaes nas classes Operao um servio que pode ser solicitado por algum objeto da classe. Como podemos observar no diagrama vrias operaes foram includas.

39

Obs: As operaes de acesso no foram includos. Operaes de acesso so aquelas que obtm (get) ou escrevem (set) o dado. recomendvel que os atributos tenham visibilidade privada e que haja uma operao get e uma set para cada atributo. Desta forma o atributo ser acessado fora da classe somente atravs de operaes, possibilitando o encapsulamento. Como teramos muitas operaes get e set elas no costumam ser includas nos diagramas de classe.

40

4. Acrescente informaes sobre os operaes A sintaxe da UML a seguinte: [visibilidade] nome [ (lista de parmetros) ] [:tipo-da-expresso-retornada] [{propriedade}]

41

 Visibilidade A visibilidade de operaes pode ser pblica, privada ou protegida. A seguir apresentada a representao e o significado desses termos: + public : Uma operao declarada como public numa classe visvel por todas as classes # protected: Uma operao declarada como protected numa classe visvel nas subclasses - private: Uma operao declarada como private visvel apenas na classe na qual foi declarada

42

43

Em Cay S. HorstMann, Gray Cornell, Core Java Fundamentals, vol. 1, Sun Microsystems, 1999, so feitas as seguintes consideraes sobre a visibilidade em Java: - Os atributos de uma classe devem ser declarados como private e os mtodos so geralmente declarados como public. Qualquer atributo declarado como private no ser visvel por outras classes e isto tambm vale para subclasses: uma subclasse no pode acessar os dados privados de sua superclasse. - H, no entanto, situaes em que se deseja que uma subclasse tenha acesso a um mtodo ou a um dado da sua classe pai. Neste caso, devemos declarar o mtodo ou a varivel como protected. Por exemplo, se o objeto dataContrataao de uma classe Empregado fosse declarado como protected em vez de private, ento os mtodos da classe Gerente (uma subclasse de empregado) poderiam acessar este campo diretamente.
44

- Na prtica evite utilizar atributos protected. Suponha que voc projetou uma classe com campos protected e que esta classe esteja sendo utilizada por outros programadores. Estes programadores podero derivar classes a partir da sua classe e, ento, podero acessar diretamente os campos definidos como protected. Voc no poder mudar a implementao da sua classe sem incomodar os outros programadores. Isto contra o esprito da programao orientada a objetos, que estimula o encapsulamento. - Mtodos do tipo protected fazem mais sentido. Uma classe complexa pode declarar um mtodo como protected e teria como vantagem que s a classe e as subclasses poderiam acessar este mtodo.

45

 Parmetros Podem ser descritos zero ou mais parmetros de acordo com a seguinte sintaxe: [direo] nome: tipo [= valor-padro] Direo: - In: um parmetro de entrada que no ser modificado - Out: um parmetro de sada que poder ser modificado - Inout: um parmetro de entrada que poder ser modificado

46

 Propriedade Exemplo de uma propriedade : Esttica determina que a operao da classe e no do objeto.

47

5. Acrescente a navegao
Inclumos uma seta de navegao em uma associao quando desejamos limitar a navegao a uma nica direo. Sem a seta de navegao a associao considerada bidirecional, como no exemplo a seguir:

C liente
c d ig o CPF nome en d ere o te l e f o n e [ 0 ..1 ] e M a i l [ 0 ..1 ] 1 n u mP e d id o

Ped id o

d a ta E m i s s o n o m e P r e s e n te a d o [ 0 ..1 ]

f a z ->

1 ..* e n d e r e o E n tr e g a d a ta C a n c e l a m e n to [ 0 ..1 ] s ta tu s

48

Especificar a direo a ser seguida no significa necessariamente que a navegao em uma das direes impossvel. A idia que possvel, partindo-se de uma extremidade, chegar direta e mais facilmente aos objetos da outra extremidade, isto porque o objeto de origem deve armazenar alguma referncia aos objetos de destino. No exemplo a seguir, mais facilmente ser encontrado o cliente que fez um dado pedido, mas pode-se tambm conhecer os pedidos de um certo cliente.
C liente
c d ig o CPF n o me en d ere o telef o n e [0 ..1] eM a il [0 ..1] 1 n u mP ed id o d a ta E miss o n o meP resen tea d o [0 ..1] 1..* en d ere o E n treg a d a ta C a n c ela men to [0 ..1] sta tu s

Pedido

49

Uma associao com seta de navegao pode ser interpretada como uma visibilidade por atributo da origem para a classe alvo. Ao ser implementada numa linguagem orientada a objetos, esta associao normalmente traduzida das seguintes formas, dependendo da multiplicidade: - a classe origem ter um atributo que referencia uma instncia da classe alvo - a classe origem ter um atributo que referencia vrias instncias da classe alvo No exemplo anterior, a classe Pedido teria, ao ser implementada, um atributo do tipo Cliente.

50

6. Acrescente relacionamentos de dependncia Este relacionamento, apresentado atravs de uma seta tracejada, indica que um elemento tem conhecimento de outro elemento. A dependncia um relacionamento entre dois itens em que a alterao de um item pode afetar a semntica do outro. Num relacionamento de dependncia a seta tracejada aponta o item do qual o outro depende.

51

No diagrama de classes o relacionamento de dependncia pode representar, por exemplo, que uma classe usa outra como argumento na assinatura de uma operao. Assim, se a classe utilizada for modificada, a operao da outra classe pode ser afetada, pois a classe utilizada pode, ao ser modificada, ter a interface ou o comportamento alterado. Uma situao deste tipo ocorre na classe ControladorDePedidos: a operao ObterFatura retorna um objeto da classe Fatura_Proj.

52

53

Outro exemplo:

54

Exerccio
Desenvolva para o projeto da PETROBRAS um caso de uso real para interface de consulta para histrico de um aluno especfico.