Diagramas

Encapsulamento

Segundo Lima (2011), encapsulamento ou ocultação de informações é uma técnica que consiste em separar aspectos externos dos internos da implementação de um objeto, isto é, determinados detalhes ficam ocultos aos demais objetos e dizem respeito apenas ao próprio objeto.

A técnica consiste no ocultamento das informações, ou seja, qualquer aplicação poderá utilizar uma determinada classe, mas não terá acesso à forma como foi definida. Os atributos e as operações encapsulados somente serão visíveis pelo próprio objeto.

Vale ressaltar que, nessa técnica, os objetos da subclasse herdam todos os atributos e operações da superclasse. Isso significa que o encapsulamento estabelece uma dependência com a relação de herança.

Ligações, associações e multiplicidade

De acordo com Blaha e Rumbaugh (2006),ligações e associações são o meio de estabelecer relacionamentos entre objetos e classes. Uma ligação é uma conexão física ou conceitual entre objetos e associação é uma descrição de um grupo de ligações com estrutura e semântica comuns.

Assim, os objetos e as classes relacionam-se por meio de uma notação específica da UML.

Além disso, há uma notação da UML chamada de multiplicidade. É uma simbologia utilizada em ligações e associações. Para Blaha e Rumbaugh (2006), “multiplicidade especifica o número de instâncias de uma classe que podem se relacionar a uma única instância de uma classe associada”.

Blaha e Rumbaugh (2006) advertem em sua obra que, apesar de a literatura utilizar esse significado, a multiplicidade é um subconjunto (possivelmente infinito) de inteiros não negativos.
Além da simbologia apresentada no exemplo, a multiplicidade permite outras possibilidades de simbologias, tais como: “1..” – um ou mais; “5..7” – cinco a sete inclusive; “0..1” – zero ou um etc. A indicação de notação de multiplicidade é considerada opcional. Portanto, se você não indicá-la, não haverá problemas, mas é recomendável usá-la.

Agregação e composição

“A agregação é uma forma especial de associação utilizada para mostrar que um tipo de objeto é composto, pelo menos em parte, de outro em uma relação de todo/parte”, afirma Furlan (1998). Assim, agregação é uma associação em que um objeto é parte do outro, ainda que a parte possa existir sem o todo.

De acordo com Medeiros (2004), para sabermos se um relacionamento é de agregação, basta perguntarmos se, em primeiro lugar, cabe a estrutura todo-parte. Em seguida, perguntamos se o objeto constituinte “vive” sem o objeto agregado. Se a resposta for sim para ambas as perguntas, teremos uma agregação.
Outro caso especial de associação, semelhante à agregação, é a composição, que é também uma forma de relacionamento todo/parte. A composição é constituída por partes (componentes) que formam o todo (composto), de maneira que o todo não existe sem as suas partes.

Para identificar uma composição, utilizaremos as mesmas perguntas utilizadas para identificar uma agregação sugeridas por Medeiros (2004). A diferença é que, se a resposta à segunda pergunta for não, você terá uma composição.

Diagrama de classe

Um diagrama de classe é representado por um conjunto de classes relacionadas entre si. É um dos diagramas mais importantes da modelagem orientada a objetos.

Diagrama de caso de uso

O diagrama de caso de uso descreve as funcionalidades do sistema, demonstrando as interações externas. Segundo o OMG (2013), um caso de uso é a especificação de um conjunto de ações executado tipicamente por um sistema que entrega um resultado observável que é de valor para um ou mais atores ou outros interessados no sistema.

Em relação ao caso de uso, é necessário identificar as funcionalidades do sistema em relação às interações com os atores. As funções indicadas nos casos de uso são ações que estes desempenham no sistema. Geralmente, utiliza-se um verbo no infinitivo acompanhado de um substantivo. Por exemplo: abrir conta, efetuar saque, atualizar histórico, realizar pagamento etc. poderiam ser casos de uso de um sistema bancário.
O ator deve interagir com o sistema por meio de relacionamentos. A comunicação ocorre por meio de linhas com ou sem setas; esta última indica um relacionamento bidirecional ou de duas direções. Vale ressaltar que as linhas utilizadas para indicar relacionamentos em diagramas de caso de uso não são fluxo de dados.
Os diagramas de caso de uso devem ser elaborados após análise e estudo aprofundados sobre o funcionamento do sistema a ser desenvolvido. Na próxima seção, esse assunto é tratado com mais detalhes.

Blaha e Rumbaugh (2006) relacionam os seguintes princípios para a construção de diagramas de casos de uso:

• Em primeiro lugar, determine os limites do sistema.
• Tenha certeza de que os atores estão focalizados. Cada um deles deve ter um propósito único e coerente.
• Cada caso de uso deve fornecer valor aos usuários.
• Relacione casos de uso e atores. Cada caso de uso deve ter pelo menos um ator, e cada ator deve participar de pelo menos um caso de uso. Um caso de uso pode envolver vários atores, e um ator pode participar de vários casos de uso.
• Lembre-se de que os casos de uso são informais. É importante não exagerar no formalismo ao especificá-los.
• Os casos de uso podem ser estruturados. Para muitas aplicações, os casos de uso individuais são completamente distintos. Para grandes sistemas, eles podem ser construídos de fragmentos menores usando relações.

 Modelagem de interações

Para elaborar um diagrama de caso de uso, é necessário um estudo detalhado sobre cada parte do funcionamento do sistema. O analista deve criar uma documentação própria para especificar cada um dos detalhes. Como sugestão, podem-se criar tabelas ou formulários em que as identificações estarão documentadas.