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
8/6/2019 Documento de Arquitetura do Software ProSchedule
http://slidepdf.com/reader/full/documento-de-arquitetura-do-software-proschedule 2/13
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
8/6/2019 Documento de Arquitetura do Software ProSchedule
http://slidepdf.com/reader/full/documento-de-arquitetura-do-software-proschedule 3/13
Documento de Arquitetura v1.0
ProSchedule 1.0 Página 3 de 13
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
8/6/2019 Documento de Arquitetura do Software ProSchedule
http://slidepdf.com/reader/full/documento-de-arquitetura-do-software-proschedule 4/13
Documento de Arquitetura v1.0
ProSchedule 1.0 Página 4 de 13
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.
8/6/2019 Documento de Arquitetura do Software ProSchedule
http://slidepdf.com/reader/full/documento-de-arquitetura-do-software-proschedule 5/13
Documento de Arquitetura v1.0
ProSchedule 1.0 Página 5 de 13
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
8/6/2019 Documento de Arquitetura do Software ProSchedule
http://slidepdf.com/reader/full/documento-de-arquitetura-do-software-proschedule 6/13
Documento de Arquitetura v1.0
ProSchedule 1.0 Página 6 de 13
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.
8/6/2019 Documento de Arquitetura do Software ProSchedule
http://slidepdf.com/reader/full/documento-de-arquitetura-do-software-proschedule 7/13
Documento de Arquitetura v1.0
ProSchedule 1.0 Página 7 de 13
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.
8/6/2019 Documento de Arquitetura do Software ProSchedule
http://slidepdf.com/reader/full/documento-de-arquitetura-do-software-proschedule 8/13
Documento de Arquitetura v1.0
ProSchedule 1.0 Página 8 de 13
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.
8/6/2019 Documento de Arquitetura do Software ProSchedule
http://slidepdf.com/reader/full/documento-de-arquitetura-do-software-proschedule 9/13
Documento de Arquitetura v1.0
ProSchedule 1.0 Página 9 de 13
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.
8/6/2019 Documento de Arquitetura do Software ProSchedule
http://slidepdf.com/reader/full/documento-de-arquitetura-do-software-proschedule 10/13
Documento de Arquitetura v1.0
ProSchedule 1.0 Página 10 de 13
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.
8/6/2019 Documento de Arquitetura do Software ProSchedule
http://slidepdf.com/reader/full/documento-de-arquitetura-do-software-proschedule 11/13
Documento de Arquitetura v1.0
ProSchedule 1.0 Página 11 de 13
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.
8/6/2019 Documento de Arquitetura do Software ProSchedule
http://slidepdf.com/reader/full/documento-de-arquitetura-do-software-proschedule 12/13
Documento de Arquitetura v1.0
ProSchedule 1.0 Página 12 de 13
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.
8/6/2019 Documento de Arquitetura do Software ProSchedule
http://slidepdf.com/reader/full/documento-de-arquitetura-do-software-proschedule 13/13
Documento de Arquitetura v1.0
ProSchedule 1.0 Página 13 de 13
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
Top Related