Documento de Arquitetura do Software ProSchedule

8/6/2019 Documento de Arquitetura do Software ProSchedule

http://slidepdf.com/reader/full/documento-de-arquitetura-do-software-proschedule 1/13

ProScheduleDocumento de Arquitetura

Versão: 1.0

Data: 11 de Outubro de 2010

Identificador do documento: TP_PS1.0



Documento de Arquitetura v1.0

ProSchedule 1.0 Página 2 de 13

Histórico de Revisões

Data Versão Descrição Autor

11/10/2010 1.0 Primeira versão do documento. Helton Eduardo Ritter, Maycon

Viana Bordin





1. INTRODUÇÃO

Neste documento serão apresentados os principais detalhes da arquitetura do software ProSchedule. A

arquitetura deste foi desenvolvida durante as fases de análise e projeto do sistema e deu origem a arquitetura do sistema,

esta composta por diagramas de classes e atividades que descrevem a estrutura do sistema e seu comportamento. As

informações aqui contidas foram utilizadas como base para o desenvolvimento do software. Este documento descreve

ainda, de forma detalhada, as técnicas aplicadas na modelagem da arquitetura, como padrões e frameworks.

2. OBJETIVOS

Este documento provê as informações necessárias para o desenvolvimento e manutenção do software, pois

ilustra as diferentes visões do software e detalha o modelo de negócios do sistema.

Este documento busca tornar compreensível a estrutura básica do software sem, entretanto, entrar em detalhes

muito específicos da linguagem de programação. Para detalhamento maior do software recomenda-se a consulta da

documentação de API gerada através do Javadoc para o ProSchedule.

3. CONSIDERAÇÕES GERAIS

Este documento representa a estrutura e comportamento do software através de diagramas UML e do modelo

ER. O documento compreende ainda a descrição do framework MVC, design patterns, exceptions.

4. RESPONSABILIDADES

Toda e qualquer modificação deste documento deve ser feita com a aprovação do responsável pela Arquitetura

de Software que tem a responsabilidade de manter o documento coerente com o software desenvolvido.

5. ARQUITETURA

A arquitetura do software foi dividida em vários módulos, cada um deles responsável por um conjunto de

funcionalidade. Estas funcionalidades foram agrupadas de acordo com as ligações existentes entre elas, as semelhanças

e interdependências existentes. Dentro de cada um desses módulos houve uma nova divisão, agora em camadas e

funções.

As camadas são:

Banco de Dados

Modelo de Negócio

Facade

Visual





Controlador do Visual

E as funções são:

Exceções

Mensagens

5.1 Banco de Dados

A camada de banco de dados é a responsável pelas transações envolvendo o banco de dados. Basicamente ela

fica responsável pela manipulação dos dados contidos nas classes de modelo do negócio. Cada uma das classes de

modelo de negócio tem também uma classe de banco de dados para a manipulação de seus dados. A forma como essas

classes são implementadas de fato não deve interferir no funcionamento do software, desde que as entradas e saídas das

classes permaneçam inalteradas.

5.2 Modelo de Negócio

O modelo de negócio compreende as classes responsáveis pelo armazenamento dos dados e também pela

realização de determinadas operações onde existe a transformação de informações através de processos, como o cálculo

de algum imposto, por exemplo. A camada de negócio será manipulada por todas as outras camadas do sistema, exceto

pela camada visual que apenas recebe as informações processadas pelo controlador do visual.

5.3 Facade

Uma facade (ou fachada) dentro do sistema é responsável pela abstração da complexidade de um componente

ou módulo, facilitando assim a utilização das funcionalidades por eles providas. Dentro da arquitetura do ProSchedule

houve a aplicação de facades para a simplificação das funcionalidades do software, a maioria delas envolvendo

transações com o banco de dados.

Através do facade foi possível esconder operações que deveriam ser realizadas em conjunto com outras para

que determinada funcionalidade fosse provida de forma correta. Por exemplo, ao adicionar uma ordem de produção no

software, o facade além de inserir a ordem de produção no banco de dados deveria criar o seqüenciamento da produção

para aquela ordem de produção, além de efetuar a validação dos dados recebidos. A questão aqui é que para quem fez

uso do facade todas essas operações se resumiram a adicionar a ordem de produção, todo o resto que foi efetuado por de

trás do facade não interessa para quem apenas quer utilizar as funcionalidades que são providas.

5.4 Visual

A camada visual é aquela que irá interagir com o usuário final do software. Ela é composta por todas as classes

e componentes que juntos montam a camada visual de um módulo. Neste projeto a camada visual foi desenvolvida

através da framework Swing, entretanto isso não impede a utilização de qualquer outro framework desktop ou web para

a criação de outras camadas visuais, com a vantagem de não ser necessário descartar as outras camadas do sistema

devido a modularização deste.





5.5 Controlador do Visual

Um dos objetivos ao modelar este software foi a de separar a lógica da parte visual de seus componentes

visuais. Isso faz parte do design pattern Presentation Model. Entretanto, a implementação deste foi feita de forma um

pouco diferente, sem a utilização de data binding devido a complexidade necessária para o controle da camada visual,

ainda assim todas as funções da camada visual foram abstraídas para a camada de controle do visual.

5.6 Exceções

Como parte de cada um dos módulos foram criadas exceções especificas para o tratamento de erros do sistema.

Elas estendem as funcionalidades básicas das exceções da linguagem Java para que seja possível o fornecimento de mais

funcionalidades. Além disso, o uso de exceções individuais para cada módulo melhorou a organização do código e dos

erros exibidos ao usuário.

Em muitas das vezes outras exceções lançadas dentro de um módulo eram absorvidas por uma exceção do

módulo, para desta forma minimizar a complexidade do erro que deveria ser exibido ao usuário.

5.7 Mensagens

Dentro do sistema foram criadas as classes de mensagens, estas responsáveis pelas mensagens exibidas pelas

exceções ao usuário.

5.8 Ilustração da Arquitetura

Figura 1 – Arquitetura do Software





A Figura 1 ilustra a arquitetura básica do sistema, dividida entre as camadas de Banco de Dados, Modelo de

Negócios, Facade, Visual e Controlador do Visual. A camada de Banco de Dados faz uso do modelo de negócios para

obter os objetos que serão salvos no banco de dados ou para criar objetos a partir das informações recuperadas do banco

de dados.

O Facade utiliza tanto a camada de negócios como a de banco de dados para manipular dados e efetuar as

transações com o banco de dados, boa parte da lógica do negócio esta nesta camada. Na parte visual do software, o

Controlador do Visual utiliza o Facade para prover a camada Visual as funcionalidades necessárias.

6. DIAGRAMAS DE PACOTES

Os diagramas de pacotes (ou packages) ilustram a modularização do software, este sendo dividido em diversas

partes, cada uma delas agrupando classes com semelhanças. A estruturação de um sistema dessa forma aliado a

minimização das interações entre classes e módulos diminui a dependência entre as classes bem como a complexidade

delas e facilita futuras modificações e aumenta a portabilidade de módulos.

6.1 Pacote Principal

Figura 2 – Pacote Principal

O pacote principal da aplicação engloba todos os outros pacotes que provêm as mais diversas funcionalidades.

O pacote core contém as classes principais do sistema, todas as funcionalidades, regras de negócio e camada visual

estão localizados neste pacote. Já o pacote util contém apenas classes mais genéricas, que podem vir a ser utilizadas em

outros projetos. O pacote main contém as telas principais do sistema, bem como as classes com as mais fundamentais

operações do sistema, como inicialização de componentes e carregamento de arquivos de configuração.

O pacote validator contém classes e arquivos pertinentes a validação de dados através da ferramenta Hibernate

Validator. O pacote hibernate também contém classes e arquivos relacionados com a ferramenta de ORM Hibernate. O

pacote resources contém imagens e qualquer outro tipo de arquivo que venha a ser utilizado pelo sistema. E o pacote

config contém arquivos de configuração necessários para a inicialização do sistema.





6.2 Pacote Core

Figura 3 – Pacote

O pacote core, como foi colocado anteriormente, contém as principais classe do sistema. Este pacote está

dividido de acordo com as funcionalidades que provê. Sendo elas: Persistência (cadastros básicos), Sequenciamento

(parte principal do sistema) e Calendário. Cada um destes pacotes possui ainda a divisão de camadas citada na seção 5.

7. DIAGRAMAS DE CLASSESAqui serão descritas as principais classes do sistema bem como as interações existentes entre elas. Esta parte do

documento se aterá as classes localizadas no pacote principal da aplicação (core).

7.1 Interações entre classes de negócio

A Figura 4 mostra parte das interações entre as classes de negócio do sistema. Basicamente, existem conjuntos

(Set) que são compostos por componentes (Component) e por detalhamentos (SetDetail) que descrevem as operações

pelas quais o conjunto passa e o tempo que leva para que essa operação seja finalizada (LeadTime). Componentes, da

mesma forma que os conjuntos, também possuem detalhamentos (ComponentDetail) que descrevem as operações e o

tempo de produção.

As operações (Operation) possuem também um tempo padrão para produção (LeadTime) e são classificadas em

tipos (OperationType). Cada operação possui o seu sequenciamento (OperationScheduling) para todos os dias (Day) de

todos os anos do calendário (Calendar). O sequenciamento também é agregado por detalhes que informam os

componentes que devem ser produzidos e a qual ordem de produção pertence este componente.





Figura 4 – Interações entre classes de negócio Pt.1

Cada dia é ainda ligado ainda as ordens de produção, formando assim o seqüenciamento mestre de produção,

que informa quando um conjunto deve começar a ser produzido. Os dias compõe ainda um calendário. As ordens de

produção (Order) são feitas por um cliente (Customer), são a solicitação de um conjunto a ser produzido e em seus

detalhamentos descrevem as quantidades a serem produzidas para cada um dos componentes do conjunto.





Figura 5 – Interações entre classes de negócio Pt.2

7.2 Classes do pacote Calendar

As classes do calendário seguem o padrão definido para as camadas do sistema, entretanto o

CalendarFacade é o responsável tanto pela classe de negócio Calendar como Day, tendo ele que

lidar com duas classes de banco de dados diferentes.





Figura 6 –

Classes do Pacote Calendar

7.3 Classes do pacote Persistence

As classes do pacote de persistência seguem todas o padrão definido para as camadas do

sistema, não havendo portanto a necessidade de ilustrá-las neste documento.

7.4 Classes do pacote Scheduling

7.4.1 ORDEM DE PRODUÇÃO (ORDER)

A ordem de produção bem como seus detalhes possuem cada uma a sua camada de banco de dados, entretanto

elas compartilham o mesmo Facade.





Figura 7 – Classes de Ordem de Produção

7.4.2 SEQUENCIAMENTO (SCHEDULING)

No seqüenciamento, quem controla as requisições da camada visual é o Facade, que controla três diferentes

classes da camada de banco de dados e de negócio.





Figura 8 – Classes de Sequenciamento

8. DIAGRAMAS DE ATIVIDADE

Os diagramas de atividade descrevem um fluxo de ações para que determinada operação seja realizada, bem

como os caminhos alternativos que podem ser tomados.

8.1 Sequenciamento da Produção

A Figura 9 ilustra o seqüenciamento da produção começando pela ordem de produção que é recebida pelo

sistema. Com a ordem salva o sistema calcula o lead time necessário para a produção do conjunto da ordem de

produção. Com o lead time do conjunto e a data de entrega é possível calcular o dia em que a ordem de produção deverá

começar a ser executada.

A partir daí duas atividades passam a ocorrer em paralelo, o seqüenciamento para os componentes e o

sequenciamento para os conjuntos. Do lado dos componentes, cada um dos que compõe o conjunto é selecionado e com

cada um dos componentes todas as operações pelas quais o componente passa são percorridas e para cada uma dessas

operações a data de início da produção é definida. Quando todos os componentes tiverem sido percorridos a atividade

terá sido finalizada.





Do outro lado, o sequenciamento do conjunto percorre cada uma das operações pelas quais o conjunto passa, e

para cada uma das operações é feito o cálculo do dia em que a operação deverá iniciar. Quando as operações acabarem a

atividade se une novamente com o sequenciamento dos componentes e o sequenciamento da ordem é salvo.

Figura 9 – Sequenciamento da Produção

Documento de Arquitetura do Software ProSchedule

Documents

Transcript of Documento de Arquitetura do Software ProSchedule