Você está na página 1de 20

Disciplina: TCC em Sistema da Informação

Aula 5: Modelos de classes de projeto


Apresentação

Nesta aula, vamos explorar as propriedades e conceitos do diagrama de classes de projeto, levando em consideração a
modelagem dos diagramas de estados e sequência, que podem ter levado à incorporação de novos métodos para as classes
envolvidas nos diversos cenários de uso do sistema.

Serão levados em consideração conceitos de coesão e acoplamento, bem como padrões de projeto e outros elementos de
reuso.

É o momento também de definir a arquitetura do sistema, através do diagrama de pacotes, mostrando o seu
particionamento e a interconexão entre as partes.

Objetivos

Explicar os conceitos, propriedades e técnicas para evoluir o diagrama conceitual de classes para diagrama de classes
de projeto;

Examinar conceitos de coesão e acoplamento, bem como padrões de projeto e outros elementos de reuso;

Aplicar a construção do diagrama de classes de projeto em seu TCC a partir do diagrama conceitual de classes.
Atividades inerentes ao projeto (ou design) de software
Conforme definido em Princípios de análise e projeto de sistemas com UML, de Eduardo Bezerra, as principais atividades
realizadas durante o projeto de software, especificamente quando evoluímos, na fase de projeto, o diagrama conceitual de classes
para diagrama de classes de projeto.

Tais atividades são:


Clique nos botões para ver as informações.
Refinamento dos aspectos estáticos e estruturais 

• Refinamento do modelo conceitual de classes, acrescentando atributos e métodos que melhor definam as
responsabilidades de cada classe.

• Pode haver classe de análise que precise ser representada por mais de 1 classe de projeto e vice-versa (embora mais
difícil).

• São revistos e definidos tipos para os atributos.

• São definidas as navegabilidades das associações entre classes.

• Refinamento dos relacionamentos de associações, que podem vir a ser composição/agregação,


generalização/especialização, classes de associação e dependências.

• Devem ser considerados aspectos como coesão e acoplamento, garantindo maior independência entre as classes. Devem
ser considerados ainda a correta aplicação do conceito de encapsulamento.

• Destaque deve ser dado a fatoração de classes, através do conceito de herança (relacionamento de generalização e
especialização entre classes) e polimorfismo.

Projeto de arquitetura 

• A arquitetura lógica, diz respeito a divisão do software em camadas, incluindo aqui o modelo MVC e o modelo em camadas
de apresentação, domínio, persistência e etc. O diagrama de pacotes é o modelo disponibilizado pela UML para
representação da arquitetura lógica.

• Aspectos relevantes a serem considerados são: subsistemas, interfaces, camadas de software, como controle e
dependência entre subsistemas.

Persistência de objetos 

• Diz respeito a forma como os objetos são armazenados de forma persistente, em geral em banco de dados, que podem ser
relacionais, objeto relacionais ou de objetos.

• A persistência pode demandar novas classes, que sejam responsáveis por esse armazenamento no banco de dados
especificado (a partir desse momento as decisões de uso de linguagem de programação e SGBD começam a ocorrer.

• Tal técnica permite que se altere apenas a classe de persistência (DAO), em caso de troca de SGBD, por exemplo.

Interface 

• As interfaces vêm sendo representadas nos diagramas de interação, como elemento através do qual se dá a interação do
usuário com o sistema. No diagrama de classes de projeto, podem tornar-se classe.
Padrões de software 

• O uso de padrões de software tem sido bastante usado em projetos de software, na tentativa de desenhar sistemas mais
consistentes, com maior reuso.

Interações
É muito importante que avaliemos os diagramas de interação, já desenvolvidos, para definir melhor as classes de projeto.

Os diagramas de interação são extremamente valiosos, pois vamos entender e raciocinar em detalhes sobre quais mensagens
enviar, para quem e em que ordem.

Podemos refletir também sobre as seguintes questões:

Quais objetos realmente precisam existir? Quais as responsabilidades de cada um?

Como os objetos interagem?

É o momento de verificar se é possível estabelecer algum padrão de projeto dentro do


princípio de aplicação de boas práticas.

Atenção

Em geral, já aprendemos que:

• Toda mensagem que chega a um objeto no diagrama de sequência ou comunicação vai representar uma operação da classe, ou
seja, um método na classe que recebe a mensagem.

Observe que ao objeto cliente chega uma mensagem de nome


procurar cliente (Id Cliente), ou seja, essa será a assinatura de
um método da classe, conforme especificado abaixo na classe
Cliente.

Ao criar os modelos de interação (sequência ou comunicação), geramos informações que complementam o modelo de classes
iniciado na fase de análise.

Dica

Avalie se o seu diagrama de classes está absolutamente compatível com os diagramas de sequência dos quais faz parte, ou seja,
se todas as mensagens que chegam na classe (avaliando o diagrama de sequência), de fato são métodos que estão nas
respectivas classes. O que estiver incompleto deve ser complementado.

Modelagem de classes de projeto


O diagrama de classes de um sistema é um só, que vai sendo refinado ao longo dos momentos de análise e projeto do
desenvolvimento desse sistema.

Iniciamos avaliando o negócio e extraindo as classes a ele relacionadas.

O diagrama conceitual de classes apresenta os principais atributos e (caso desejado) os métodos derivados dos casos de uso.

Com a construção do diagrama de interação (sequência ou comunicação), começamos os refinamentos, que encerram ao final
do momento de projeto ou design do sistema. Assim, novas classes, relacionadas à forma de implementação, vão sendo criadas.
Novos métodos das classes existentes vão sendo adicionados, para adequar melhor a solução com as tecnologias propostas ou
alternativas.

Novas classes de negócio também podem ser inseridas nesse momento do processo de
desenvolvimento, mas isso com certeza vai representar ou novos requisitos que estão
sendo adicionados, ou falha técnica no momento anterior, onde os requisitos foram
identificados e definidos como presentes no escopo do sistema.
Outra tese famosa é a de Martin Dibelius, professor da Universidade de Heidelberg no início do século XX. Ele afirmava que Lucas,
o autor, utilizou um diário de viagens escrito por um companheiro de Paulo, tendo ele também participado de viagens de Paulo.

O argumento principal dessa hipótese é o fato de, em alguns trechos de Atos, ser
utilizado o pronome pessoal da primeira pessoa do plural, “nós”, enquanto que em
outros trechos não é usado.

Vielhauer (2015) concorda que um itinerário de viagens foi utilizado como fonte, mas afirma que o autor de Atos não pode ter sido
uma testemunha ocular e alguém próximo de Paulo, argumentando que são cometidos por ele equívocos históricos.

Ele cita a afirmação de que houve uma segunda viagem missionária a Jerusalém, antes do Concílio, o que entra em contradição
com o que Paulo diz em Gálatas 1,17-2,1 e com o Decreto dos Apóstolos (At 15,23-29), que contradiz Gálatas 2,6-9.

A seguir, eis algumas situações que nos fazem acrescentar classes ao modelo conceitual, dando origem ao modelo de classes de
projeto:

Classes de fronteira: interface entre a aplicação e as entidades externas (usuários, sistemas, equipamentos). Os atores
1 comunicam-se apenas com essas classes. Dessa forma, mudanças na interface não interferem nas classes de entidade,
persistência e controle. Não devem conter lógica do negócio (melhor coesão).

Classes de controle: as mais conhecidas são as que controlam a realização de um caso de uso (em geral, uma classe de
2 controle). Casos de uso simples, como cadastramentos, não necessitam de classes de controle. Classes de controle
geram uma camada entre as classes de fronteira e a classe de entidade.

3 Classes que sirvam de base para implementação do mecanismo de herança, as chamadas classes abstratas.

4 Controle de segurança (autorização e autenticação de acesso): usuário, perfis de acesso e login/logout.

5 Registro de ações realizadas no sistema (guardar os logs de acesso).

6 Classes de transações

7 Acesso e armazenamento

Veja abaixo a relação entre as classes de fronteira, entidade e controle.


• A classe de controle passa o “comando” para a classe de
fronteira (Boundary);

• O usuário interage com a classe de fronteira e devolve o


comando para a classe de controle;

• A classe de controle repassa para a classe de agência os


dados do saldo a consultar, pois é esta última classe que
conhece as suas contas.


Fonte: ARAÚJO, 2009.

Cada situação exemplificada implica na necessidade de novas responsabilidades do sistema, que demandam novas classes a ser
projetadas.

A reutilização também está presente no projeto do software, através de padrões de projeto, bibliotecas de classes (coleção de
classes com objetivo determinado), frameworks (coleção de classes em colaboração, como o hibernate e JUnit) e componentes.

Além de novas classes, vamos também refinar as classes definidas no modelo conceitual de classes, no que se refere:

À visibilidade de atributos e métodos;

Aos detalhes das assinaturas dos métodos, como os argumentos adequados, e o tipo de dado que retorna;

À análise da possibilidade de uso da herança;

À identificação de novos métodos pela análise das interações dos diagramas de sequência e/ou comunicação;

À substituição de relacionamentos de associações por outros mais semanticamente adequados; por exemplo:

Agregação;

Composição;

Classe de relacionamento;

Dependência.

Passando da Análise ao Projeto: Classes


A seguir, veremos uma classe típica de um modelo conceitual, onde são apresentados os principais atributos e métodos obtidos
diretamente do diagrama de casos de uso, ou de outra técnica, onde poucos detalhes são apresentados.

O nome da classe
que representa algo relevante para o negócio.
2

Os nomes dos principais atributos


a partir dos dados recuperados da especificação textual dos casos de uso, sem especificar detalhes como visibilidade e tipos
dos dados (inteiro, real, string etc.).

Os nomes dos métodos derivados de casos de uso


mas sem detalhes como parâmetros.

Saiba mais

Veja a representação da classe fornecedor <galeria/aula5/docs/PDF_Aula_Classe fornecedor.pdf> em um diagrama de classes de


projet.o, derivado do modelo conceitual de classes em que são acrescentados detalhes de projeto.

No diagrama conceitual de classes não há preocupação na identificação exata dos relacionamentos. De forma geral, são
indicados como associações.

Na elaboração do diagrama conceitual de classes, temos que nos preocupar com a melhor forma de implementar.

Considere o seguinte trecho de um diagrama conceitual de classes:

Veremos mais exemplos de derivação de diagrama de classes de projeto com base no diagrama conceitual de classes e algumas
decisões de implementação.

Adiante, um dos possíveis trechos de diagrama de classes de projeto:


Além do detalhamento dos atributos (aqui não exemplificamos métodos, propositalmente), adicionamos ao modelo de projeto:

1 A inclusão da classe Itens do Pedido, pois é necessário conhecer os produtos que pertencem a um pedido.

Assim sendo, o Pedido passa a ser composto de ItensPedido, pelo relacionamento de composição (a vida de Itens Pedido
2 depende de Pedido, ou seja, é criado e destruído por objetos da classe Pedido). E a classe itens Pedido refere-se à classe
produto. Foram adicionadas as multiplicidades dos novos relacionamentos identificados.

3 Como as vendas podem ter descontos unitários de produto, adicionou-se o atributo Desconto Unit na classe Itens Pedido.

Outra decisão de projeto foi a inclusão dos atributos Valor Pedido e Impostos Pedido, que vão armazenar o total do
4 pedido e o total de impostos a ser recolhidos por pedido. Tal decisão deu-se pela necessidade de uma lei vigente de
informar tais dados ao fisco.

Na classe ProdutosE foi incluído um atributo Perc Imposto, que visa a informar o percentual de imposto daquele produto,
5 na venda. Esse atributo é a base para que se possa armazenar o atributo Impostos Pedido que soma o valor de todos os
impostos de todos os itens constantes no pedido.

Vamos demonstrar agora a utilidade dos modelos de interação para a construção do modelo conceitual de classes. Para tal,
vamos construir um diagrama de sequência, tomando por base:

O trecho de diagrama de casos de uso, representado pela figura;

A especificação textual do caso de uso: Registrar Pedido, conforme abaixo;

O trecho do diagrama de classes de projeto, representado pela figura.


Especificação do Caso de Uso: Registrar Pedido

Objetivo: registrar os pedidos solicitados pelos clientes

Ator(s): Atendente

Clique nos botões para ver as informações.


Cenário Principal 

1. Atendente informa Id Cliente

2. Sistema Localiza Cliente

3. Para cada Item a ser inserido no pedido


3.1. Atendente informa Id Produto

3.2. Sistema localiza Produto

3.3. Atendente informa quantidade de produto

3.4. Sistema valida quantidade de produto

3.5. Sistema registra item do pedido

4. Atendente confirma dados do pedido

5. Sistema registra pedido

Cenários Alternativos 

2.a. Cliente não cadastrado

1. Sistema informa “Cliente não cadastrado”

2. << Extends Incluir Cliente >>

2.a. Produto não cadastrado

1. Sistema informa: “Produto não cadastrado”

2. Sistema retorna ao passo 3.1 do cenário principal

4.a. Sem estoque suficiente

1. Sistema informa: “Não há estoque suficiente do produto para a quantidade informada”

2. Sistema retorna ao passo 3.3. do cenário principal

Com base nos diagramas e especificações acima, o diagrama de sequência do cenário principal do caso de uso Registrar Pedido
pode ficar (tem outras soluções) conforme abaixo.

O diagrama de sequência conta a


estória do caso de uso Registrar Pedido,
mostrando as classes que interagem e
quais mensagens são trocadas entre
eles.

Dessa solução, que é uma das possíveis, observe:

O método Inicializar Pedido, da classe PedidoE vai iniciar o pedido, gerando o número do pedido, através do método Gera
1 NumPedido, também da Classe PedidoE, criando ainda o objeto Itens Pedido, que vai armazenar os itens do pedido
inicializado, através do método Criar ItemPed, que tem como parâmetro o Num. Pedido que acabou de ser gerado.

Observe o lopp, quadrado que circunda desde o Item Pedido informado pelo Atendente até o retorno do método Incluir
Item Pedido (Num Pedido, Id Produto, Qtde Produto). Ele indica que todas as entradas de dados e métodos com seus
2 respectivos retornos são repetidos, conforme indicado na especificação textual do cenário principal do caso de uso em
questão (Registrar Pedido).

Observe que, a cada Produto e respectiva quantidade informados pelo atendente, e após verificações de produto
3 existente e quantidade em estoque, o item do pedido é registrado pelo método Incluir Item Pedido (Num Pedido, Id
Produto, Qtde Produto) da classe Itens Pedido.

4 Ao final, após o fim do loop, o pedido é confirmado pelo Atendente, e então é finalizado (registro efetivamente inserido).

Outra situação que deve ser analisada é a representação de herança no diagrama conceitual de classes, conforme abaixo
explicitado:

Fonte: Extraído do livro proprietário da disciplina Modelagem de Sistemas [Seses].

Ao pensar no modelo conceitual de classes, temos três possibilidades:

Clique nos botões para ver as informações.


Opção 1: Manter as mesmas classes 

Quando as três classes têm relacionamentos individuais e há uma quantidade equivalente e equilibrada de atributos nas
quatro classes.

Opção 2: Manter apenas a classe pai (Funcionário) 

Quando a classe pai tem a maioria de relacionamentos e atributos. Nesse caso, essa classe absorve todos os atributos,
métodos e relacionamentos das classes filhas.

Opção 3: Manter apenas as classes filhas (diretoria, gerência e operação) 

Ou seja, a classe pai não tem relacionamentos ou atributos específicos. Mas pode ser mantida no modelo, como uma classe
abstrata1 , ou seja, não tem atribuição específica no contexto, mas incorpora o que há de comum entre as filhas. Também
pode ser eliminada, dependendo da solução desejada.
Comentário

No exemplo ilustrado no trecho de diagrama de classes , vemos a classe empregado atuando como classe abstrata. Essa deve ter
ao menos um método abstrato.

Nesse exemplo, a classe empregada tem o método abstrato Vencimento() implementado pelo método de mesma assinatura, mas
com os respectivos códigos implementados, conforme o tipo de empregado (assalariado, comissionado e horista).

Conceitos de acoplamento e coesão


Quando falamos em arquitetura de um sistema, estamos falando de sua organização em partes, das relações de dependências
entre as partes e da forma como dividimos os elementos do sistema entre essas partes.

Quando falamos de partes, estamos nos referindo a subsistemas, módulos, pacotes, classes, componentes, métodos de uma
classe ou qualquer outra forma de organizar os elementos de um sistema.

Há dois conceitos relevantes que estão diretamente relacionados ao conceito de arquitetura de software: acoplamento e coesão.

Acoplamento Coesão

compare_arrows
Diz respeito a dependência entre as partes, a forma Diz respeito ao grau de dependências entre os
como estão relacionadas ou acopladas. elementos internos das partes do sistema.

Continue lendo... Continue lendo...


As classes precisam ser construídas levando em consideração a análise de coesão
entre as suas funcionalidades e ainda a avaliação do acoplamento entre as classes.

Considere, ainda nessa análise sobre as classes, o conceito de responsabilidade, que veremos mais detalhadamente a seguir.

Responsabilidade das classes


Uma das formas mais clássicas de pensar sobre projeto de objetos em um software diz respeito à responsabilidades, papéis e
colaborações.

A UML define responsabilidade como “um contrato ou obrigação de um classificador”.

Responsabilidade tem relação com o que o objeto precisa fazer para exercer seu papel no contexto. Basicamente:

Fazer Conhecer
algo em prol da colaboração, seja criando um objeto, os dados e os objetos relacionados.
calculando, controlando demais objetos e etc.

As responsabilidades dos objetos são identificadas durante a fase ou disciplina de projeto de software.

A ideia de colaboração está intimamente relacionada com o conceito de responsabilidade. Responsabilidades são implementadas
por métodos, que atuam por si só ou colaboram com métodos de objetos relacionados. Os diagramas de interação são
extremamente úteis para atribuir responsabilidades às classes.

Diagrama de classe.

A classe PedidoE é responsável por criar Itens Pedido (responsabilidade de fazer), e por conhecer o seu total (responsabilidade de
conhecer).

Sobre essa responsabilidade, para conhecer o seu total, a classe faz uso do método Obter
TotalPed (). Mas não faz isso sozinho. Precisa de colaboração da classe Itens Pedido,
através do método Obter Sub Total Ped (), pois quem conhece o total de cada linha de item
do pedido é a própria classe Itens Pedido.

Conceito de Interface
Outro conceito que deve ser incorporado a sua visão de agregar mais detalhes ao diagrama de classes de projeto é o de interface.
Uma classe pode ter em uma instância um objeto real, ao
passo que a interface precisa de uma classe para implementá-
la.

Observe a imagem onde, na parte superior do retângulo, que


representa a classe, é apresentado o estereótipo «interface».


Representação de uma interface.

Dica

A partir da versão 2.0 da UML, uma interface é considerada uma especialização de uma classe e é desenhada como uma classe.

Uma interface é útil quando não se pode implementar herança múltipla (na linguagem de programação que se pretende usar),
mas permite inúmeras interfaces.

As classes que implementarem o conceito de interface passam a incorporar todos os


métodos da interface ou se transformam em uma classe abstrata.

Aplicando em seu TCC, o diagrama de classes de projeto e


diagrama de pacotes
Aplicando os conteúdos aqui ministrados, elabore o diagrama de classes de projeto, considerando o seu diagrama conceitual de
classes, construído na disciplina de Projeto de TCC em Sistemas de Informação.
• Caso seja necessário alterar diagramas de interação em função de novas formas de implementar uma determinada solução, não
há qualquer problema. Apenas avise ao seu orientador-tutor e, ao mandar o projeto como um todo, agregue essas eventuais
mudanças.

• Conforme identificar métodos de classes que tenham algoritmos complexos e/ou que tenham atividades realizadas em paralelo,
faça anotações, pois o próximo passo é justamente a elaboração do diagrama de atividades para esses métodos.

• Cabe lembrar que a cada momento de evolução no projeto você deve registrar as bibliografias consultadas, independentemente
do tipo de mídia.

Atividade
1. No que se refere às atividades inerentes ao projeto de objetos:

I. O diagrama conceitual de classes já traz as classes completas em termos da definição dos atributos.

II. Refinamento das classes, com inserção de classes de software (de projeto).

III. Inserção de métodos nas classes, com atribuições de responsabilidades.

Com base em sua análise, assinale a única alternativa correta:

a) Estão corretas apenas II e III.


b) Está correta apenas I.
c) Estão corretas I, II e III.
d) Estão corretas apenas I e II.
e) Estão corretas apenas I e III.
2. Analise as duas assertivas a seguir e a relação entre elas:

I. No modelo de classes de projeto podemos incluir novos atributos nas classes

PORQUE

II. No modelo conceitual de classes não representamos atributos.

Com base em análise , assina a resposta correta quanto a assertividade de cada uma e sobre a relação entre elas.

a) As duas assertivas estão corretas e a segunda justifica a primeira.


b) As duas assertivas estão corretas e a segunda não justifica a primeira.
c) As duas assertivas estão erradas.
d) A assertiva I está correta e a assertiva II está errada.
e) A assertiva I está errada e a assertiva II está correta.

Notas

Classe abstrata 1

São “modelos” para classes que forem suas herdeiras. Não pode ser instanciada (ter objeto a ela associado). Para ter um objeto
de uma classe abstrata é necessário criar uma classe mais especializada, herdando dela e então instanciar essa nova classe.
Seus métodos devem ser sobrescritos, em suas classes filhas.

Tais classes abstratas trazem consigo o conceito de métodos abstratos, implementados em suas subclasses para definir um
comportamento específico. O método abstrato define tão somente a assinatura do método e não possui código, que estará em
cada classe especializada que desejar implementar aquele método (assinatura) de forma diferenciada, específica.

Acoplamento

Partindo do próprio conceito de sistema, temos que sistema é um conjunto de partes independentes, cada qual realizando seu
trabalho, que juntas colaboram para um objetivo maior, em comum. Ou seja, as partes devem ser independentes ou pouco
dependentes.

O acoplamento, assim, mede o grau de interdependência entre essas partes. Dessa forma, os sistemas devem ser organizados
para ter baixo acoplamento ou baixa dependência.

O alto acoplamento entre as partes pode gerar dificuldade de:

• Alteração no sistema, uma vez que existe dependência entre as partes (a alteração em uma parte pode demandar reflexos nas
que dela dependem);

• Reutilização, uma vez que depende da presença de outras partes.

Coesão
Podemos dizer que a coesão mede, por exemplo, o grau de afinidade entre as funcionalidades de cada parte do sistema. As
funcionalidades de uma parte devem levar ao desenvolvimento de apenas uma tarefa e, nesse caso, devemos perseguir a alta
coesão, ou seja, que a afinidade entre as funcionalidades seja alta.

Uma parte com baixa coesão faz muitas coisas não relacionadas, e apresenta dificuldades de:

• Entendimento das partes e consequentemente do sistema.

• Reutilização, na medida em que a parte não realiza uma tarefa única.

• Manutenção

Referências

BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. 3.ed. Rio de Janeiro: Elsevier, 2015. Cap. 3.

BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. UML - Guia do Usuário. 2.ed. Rio de Janeiro: Elsevier, 2005. cap. 1 e 2.

FOWLER, Martin. UML Essencial - Um Breve Guia Para a Linguagem-Padrão. 3.ed. Porto Alegre: Artmed, 2005. cap. 1.

LARMAN, Craig. Utilizando UML e Padrões? Uma Introdução à Análise e ao Projeto Orientados a Objetos e ao Processo
Unificado. 3.ed. Porto Alegre: Artmed, 2007. cap. 2.

Próxima aula

Detalhar lógica de métodos complexos e/ou com atividades em paralelo, usando o diagrama de atividades da UML;

Desenvolver o Diagrama de Atividades em seu TCC.

Explore mais

Leia os seguintes textos:

Engenharia de Software 2 - Análise Orientada a Objetos. Saiba como chegar a um modelo OO focado em responsabilidades a
partir de casos de uso <https://www.devmedia.com.br/artigo-engenharia-de-software-2-analise-orientada-a-objetos/9150> .
Acesso em: 02 jan. 2019.

O diagrama de classes
<https://www.ibm.com/developerworks/br/rational/library/content/RationalEdge/sep04/bell/index.html> . Uma introdução aos
diagramas de estrutura em UML 2. Acesso em: 02 jan. 2019.

Polimorfismo, classes abstratas e interfaces: fundamentos da POO em Java <https://www.devmedia.com.br/polimorfismo-


classes-abstratas-e-interfaces-fundamentos-da-poo-em-java/26387> . Acesso em: 02 jan. 2019.

Visite também a página da Unified Modeling Language (UML) <//www.uml.org/> . Acesso em: 02 jan. 2019.

Você também pode gostar