ProSchedule Documento de Arquitetura

Verso: Data:

1.0 11 de Outubro de 2010

Identificador do documento: TP_PS1.0

Documento de Arquitetura

v1.0

Histrico de Revises

Data 11/10/2010

Verso 1.0

Descrio Primeira verso do documento.

Autor Helton Eduardo Ritter, Maycon Viana Bordin

ProSchedule 1.0

Pgina 2 de 13

Documento de Arquitetura

v1.0

1. INTRODUO
Neste documento sero apresentados os principais detalhes da arquitetura do software ProSchedule. A arquitetura deste foi desenvolvida durante as fases de anlise 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 informaes aqui contidas foram utilizadas como base para o desenvolvimento do software. Este documento descreve ainda, de forma detalhada, as tcnicas aplicadas na modelagem da arquitetura, como padres e frameworks.

2. OBJETIVOS
Este documento prov as informaes necessrias para o desenvolvimento e manuteno do software, pois ilustra as diferentes vises do software e detalha o modelo de negcios do sistema. Este documento busca tornar compreensvel a estrutura bsica do software sem, entretanto, entrar em detalhes muito especficos da linguagem de programao. Para detalhamento maior do software recomenda-se a consulta da documentao de API gerada atravs do Javadoc para o ProSchedule.

3. CONSIDERAES GERAIS
Este documento representa a estrutura e comportamento do software atravs de diagramas UML e do modelo ER. O documento compreende ainda a descrio do framework MVC, design patterns, exceptions.

4. RESPONSABILIDADES
Toda e qualquer modificao deste documento deve ser feita com a aprovao do responsvel 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 vrios mdulos, cada um deles responsvel por um conjunto de funcionalidade. Estas funcionalidades foram agrupadas de acordo com as ligaes existentes entre elas, as semelhanas e interdependncias existentes. Dentro de cada um desses mdulos houve uma nova diviso, agora em camadas e funes. As camadas so: ProSchedule 1.0 Banco de Dados Modelo de Negcio Facade Visual Pgina 3 de 13

Documento de Arquitetura

v1.0

Controlador do Visual

E as funes so: Excees Mensagens

5.1 Banco de Dados

A camada de banco de dados a responsvel pelas transaes envolvendo o banco de dados. Basicamente ela fica responsvel pela manipulao dos dados contidos nas classes de modelo do negcio. Cada uma das classes de modelo de negcio tem tambm uma classe de banco de dados para a manipulao de seus dados. A forma como essas classes so implementadas de fato no deve interferir no funcionamento do software, desde que as entradas e sadas das classes permaneam inalteradas.

5.2 Modelo de Negcio

O modelo de negcio compreende as classes responsveis pelo armazenamento dos dados e tambm pela realizao de determinadas operaes onde existe a transformao de informaes atravs de processos, como o clculo de algum imposto, por exemplo. A camada de negcio ser manipulada por todas as outras camadas do sistema, exceto pela camada visual que apenas recebe as informaes processadas pelo controlador do visual.

5.3 Facade
Uma facade (ou fachada) dentro do sistema responsvel pela abstrao da complexidade de um componente ou mdulo, facilitando assim a utilizao das funcionalidades por eles providas. Dentro da arquitetura do ProSchedule houve a aplicao de facades para a simplificao das funcionalidades do software, a maioria delas envolvendo transaes com o banco de dados. Atravs do facade foi possvel esconder operaes que deveriam ser realizadas em conjunto com outras para que determinada funcionalidade fosse provida de forma correta. Por exemplo, ao adicionar uma ordem de produo no software, o facade alm de inserir a ordem de produo no banco de dados deveria criar o seqenciamento da produo para aquela ordem de produo, alm de efetuar a validao dos dados recebidos. A questo aqui que para quem fez uso do facade todas essas operaes se resumiram a adicionar a ordem de produo, todo o resto que foi efetuado por de trs do facade no interessa para quem apenas quer utilizar as funcionalidades que so providas.

5.4 Visual
A camada visual aquela que ir interagir com o usurio final do software. Ela composta por todas as classes e componentes que juntos montam a camada visual de um mdulo. Neste projeto a camada visual foi desenvolvida atravs da framework Swing, entretanto isso no impede a utilizao de qualquer outro framework desktop ou web para a criao de outras camadas visuais, com a vantagem de no ser necessrio descartar as outras camadas do sistema devido a modularizao deste.

ProSchedule 1.0

Pgina 4 de 13

Documento de Arquitetura

v1.0

5.5 Controlador do Visual

Um dos objetivos ao modelar este software foi a de separar a lgica da parte visual de seus componentes visuais. Isso faz parte do design pattern Presentation Model. Entretanto, a implementao deste foi feita de forma um pouco diferente, sem a utilizao de data binding devido a complexidade necessria para o controle da camada visual, ainda assim todas as funes da camada visual foram abstradas para a camada de controle do visual.

5.6 Excees
Como parte de cada um dos mdulos foram criadas excees especificas para o tratamento de erros do sistema. Elas estendem as funcionalidades bsicas das excees da linguagem Java para que seja possvel o fornecimento de mais funcionalidades. Alm disso, o uso de excees individuais para cada mdulo melhorou a organizao do cdigo e dos erros exibidos ao usurio. Em muitas das vezes outras excees lanadas dentro de um mdulo eram absorvidas por uma exceo do mdulo, para desta forma minimizar a complexidade do erro que deveria ser exibido ao usurio.

5.7 Mensagens
Dentro do sistema foram criadas as classes de mensagens, estas responsveis pelas mensagens exibidas pelas excees ao usurio.

5.8 Ilustrao da Arquitetura

Figura 1 Arquitetura do Software ProSchedule 1.0 Pgina 5 de 13

Documento de Arquitetura

v1.0

A Figura 1 ilustra a arquitetura bsica do sistema, dividida entre as camadas de Banco de Dados, Modelo de Negcios, Facade, Visual e Controlador do Visual. A camada de Banco de Dados faz uso do modelo de negcios para obter os objetos que sero salvos no banco de dados ou para criar objetos a partir das informaes recuperadas do banco de dados. O Facade utiliza tanto a camada de negcios como a de banco de dados para manipular dados e efetuar as transaes com o banco de dados, boa parte da lgica do negcio esta nesta camada. Na parte visual do software, o Controlador do Visual utiliza o Facade para prover a camada Visual as funcionalidades necessrias.

6. DIAGRAMAS DE PACOTES
Os diagramas de pacotes (ou packages) ilustram a modularizao do software, este sendo dividido em diversas partes, cada uma delas agrupando classes com semelhanas. A estruturao de um sistema dessa forma aliado a minimizao das interaes entre classes e mdulos diminui a dependncia entre as classes bem como a complexidade delas e facilita futuras modificaes e aumenta a portabilidade de mdulos.

6.1 Pacote Principal

Figura 2 Pacote Principal O pacote principal da aplicao engloba todos os outros pacotes que provm as mais diversas funcionalidades. O pacote core contm as classes principais do sistema, todas as funcionalidades, regras de negcio e camada visual esto localizados neste pacote. J o pacote util contm apenas classes mais genricas, que podem vir a ser utilizadas em outros projetos. O pacote main contm as telas principais do sistema, bem como as classes com as mais fundamentais operaes do sistema, como inicializao de componentes e carregamento de arquivos de configurao. O pacote validator contm classes e arquivos pertinentes a validao de dados atravs da ferramenta Hibernate Validator. O pacote hibernate tambm contm classes e arquivos relacionados com a ferramenta de ORM Hibernate. O pacote resources contm imagens e qualquer outro tipo de arquivo que venha a ser utilizado pelo sistema. E o pacote config contm arquivos de configurao necessrios para a inicializao do sistema. ProSchedule 1.0 Pgina 6 de 13

Documento de Arquitetura

v1.0

6.2 Pacote Core

Figura 3 Pacote O pacote core, como foi colocado anteriormente, contm as principais classe do sistema. Este pacote est dividido de acordo com as funcionalidades que prov. Sendo elas: Persistncia (cadastros bsicos), Sequenciamento (parte principal do sistema) e Calendrio. Cada um destes pacotes possui ainda a diviso de camadas citada na seo 5.

7. DIAGRAMAS DE CLASSES
Aqui sero descritas as principais classes do sistema bem como as interaes existentes entre elas. Esta parte do documento se ater as classes localizadas no pacote principal da aplicao (core).

7.1 Interaes entre classes de negcio

A Figura 4 mostra parte das interaes entre as classes de negcio do sistema. Basicamente, existem conjuntos (Set) que so compostos por componentes (Component) e por detalhamentos (SetDetail) que descrevem as operaes pelas quais o conjunto passa e o tempo que leva para que essa operao seja finalizada (LeadTime). Componentes, da mesma forma que os conjuntos, tambm possuem detalhamentos (ComponentDetail) que descrevem as operaes e o tempo de produo. As operaes (Operation) possuem tambm um tempo padro para produo (LeadTime) e so classificadas em tipos (OperationType). Cada operao possui o seu sequenciamento (OperationScheduling) para todos os dias (Day) de todos os anos do calendrio (Calendar). O sequenciamento tambm agregado por detalhes que informam os componentes que devem ser produzidos e a qual ordem de produo pertence este componente.

ProSchedule 1.0

Pgina 7 de 13

Documento de Arquitetura

v1.0

Figura 4 Interaes entre classes de negcio Pt.1 Cada dia ainda ligado ainda as ordens de produo, formando assim o seqenciamento mestre de produo, que informa quando um conjunto deve comear a ser produzido. Os dias compe ainda um calendrio. As ordens de produo (Order) so feitas por um cliente (Customer), so a solicitao de um conjunto a ser produzido e em seus detalhamentos descrevem as quantidades a serem produzidas para cada um dos componentes do conjunto.

ProSchedule 1.0

Pgina 8 de 13

Documento de Arquitetura

v1.0

Figura 5 Interaes entre classes de negcio Pt.2

7.2 Classes do pacote Calendar As classes do calendrio seguem o padro definido para as camadas do sistema, entretanto o CalendarFacade o responsvel tanto pela classe de negcio Calendar como Day, tendo ele que lidar com duas classes de banco de dados diferentes.
ProSchedule 1.0 Pgina 9 de 13

Documento de Arquitetura

v1.0

Figura 6 Classes do Pacote Calendar

7.3 Classes do pacote Persistence As classes do pacote de persistncia seguem todas o padro definido para as camadas do sistema, no havendo portanto a necessidade de ilustr-las neste documento. 7.4 Classes do pacote Scheduling
7.4.1 ORDEM DE PRODUO (ORDER) A ordem de produo bem como seus detalhes possuem cada uma a sua camada de banco de dados, entretanto elas compartilham o mesmo Facade.

ProSchedule 1.0

Pgina 10 de 13

Documento de Arquitetura

v1.0

Figura 7 Classes de Ordem de Produo 7.4.2 SEQUENCIAMENTO (SCHEDULING) No seqenciamento, quem controla as requisies da camada visual o Facade, que controla trs diferentes classes da camada de banco de dados e de negcio.

ProSchedule 1.0

Pgina 11 de 13

Documento de Arquitetura

v1.0

Figura 8 Classes de Sequenciamento

8. DIAGRAMAS DE ATIVIDADE
Os diagramas de atividade descrevem um fluxo de aes para que determinada operao seja realizada, bem como os caminhos alternativos que podem ser tomados.

8.1 Sequenciamento da Produo

A Figura 9 ilustra o seqenciamento da produo comeando pela ordem de produo que recebida pelo sistema. Com a ordem salva o sistema calcula o lead time necessrio para a produo do conjunto da ordem de produo. Com o lead time do conjunto e a data de entrega possvel calcular o dia em que a ordem de produo dever comear a ser executada. A partir da duas atividades passam a ocorrer em paralelo, o seqenciamento para os componentes e o sequenciamento para os conjuntos. Do lado dos componentes, cada um dos que compe o conjunto selecionado e com cada um dos componentes todas as operaes pelas quais o componente passa so percorridas e para cada uma dessas operaes a data de incio da produo definida. Quando todos os componentes tiverem sido percorridos a atividade ter sido finalizada.

ProSchedule 1.0

Pgina 12 de 13

Documento de Arquitetura

v1.0

Do outro lado, o sequenciamento do conjunto percorre cada uma das operaes pelas quais o conjunto passa, e para cada uma das operaes feito o clculo do dia em que a operao dever iniciar. Quando as operaes acabarem a atividade se une novamente com o sequenciamento dos componentes e o sequenciamento da ordem salvo.

Figura 9 Sequenciamento da Produo

ProSchedule 1.0

Pgina 13 de 13