A Modelagem de Objetos Usando a UML

Modelagem de Objetos Usando a UML

Conceitos básicos de Orientação a Objetos

Atualmente trabalha-se o conceito de modelagem orientada a objetos, para implementação de softwares, a orientação a objetos vê tudo no mundo real (que irá ser informatizado), como objetos que se interagem entre si, formando assim o sistema. Os principais objetivos da orientação a objetos são: diminuir a distância entre o mundo real (o problema) e o modelo abstrato (solução); e trabalhar noções intuitivas (objetos e ações) durante todo o ciclo de vida, atrasando, ao máximo, a introdução de conceitos de implementação.

A orientação a objetos trabalha baseando-se em componentes, assim, a alteração de um componente não afeta o projeto ao todo, pois esses componentes trabalham através de mensagens.

A orientação a objetos tem por objetivos: enfrentar novos domínios e aplicações; melhorar a interação entre analistas e especialistas; aumentar os resultados da análise; representação básica consistente para a análise e o projeto; alterabilidade, legibilidade e extensibilidade; possibilidade de ciclos de desenvolvimento variados; apoio ao reuso.

Como os paradigmas de orientação a objetos vê que o mundo é povoados de objetos, esses são agrupados em classes de acordo com suas características, os conceitos principais da orientação a objetos são:

Objeto – uma entidade que possui um estado, dado por seus atributos, exibe um comportamento definido e identidade própria.

Classe – reúne um conjunto de objetos com a mesma característica e comportamento, sendo que esses objetos são tidos como instâncias dessa classe.

Ligação e Associação – ligações e associações são meios de representar a comunicação entre objetos ou classes, sendo uma associação um conjunto de ligações.

Herança – é um mecanismo para modelar similaridades entre classes, representando as abstrações de generalização e especialização. O mecanismo de herança possibilita reutilização, captura explícita de características comuns e definição incremental de classes.

Método – é uma implementação real de uma operação.

Mensagens – são meios de comunicação entre objetos e são responsáveis pela ativação de todo e qualquer processamento.

A Linguagem de Modelagem Unificada

Com a necessidade de padronizar a simbologia adotada nos diversos artefatos produzidos no processo de software, criou-se em 1997, a Linguagem de Modelagem Unificada, a UML que é o padrão para especificar, visualizar, documentar e construir artefatos de um sistema e pode ser usada em todos os processos de desenvolvimento orientado a objetos.

A UML possui treze diagramas e vai além de uma simples padronização em busca de uma notação unificada, uma vez que contém conceitos novos que não são encontrados em outro métodos orientados a objetos.

Levantamento de Requisitos

Logo no início de um projeto temos a tarefa mais difícil, o levantamento de requisitos, pois através dele que todo o sistema será construído, os requisitos são definidos juntamente com o cliente e ele define o que o sistema irá fazer e como essa tarefa será desenvolvida, um erro no levantamento de requisitos pode comprometer todo projeto, sendo assim é necessário que o profissional responsável por esse levantamento, tenha um nível de abstração bastante alto.

Para representar e validar esses requisitos com o cliente, são usados os casos de uso, que representa a interação de determinado requisito com um usuário humano ou outro sistema. O caso de uso possui dois importantes papéis: de capturar os requisitos funcionais de um sistema – um modelo de caso de uso define o comportamento de um sistema; oferece uma abordagem para a modelagem de sistemas.

A captura dos casos de uso é a primeira atividade a ser realizada no desenvolvimento, propriamente dito. A maioria dos casos de uso é normalmente gerada durante a fase de levantamento de requisitos, mas outros casos de uso podem ser descobertos à medida que o trabalho prossegue.

Os diagramas de caso de uso detalham as funcionalidades e quem estará operando o sistema. Ele é composto por dois elementos o atore e os casos de uso, sendo que o ator representa um usuário, outro sistema ou dispositivo que desempenha com respeito ao sistema; e os casos de uso representam as funcionalidades requeridas externamente.

Quando um ator interage com um sistema, ele segue uma seqüência de operações tal seqüência define o caso de uso.

Porém o diagrama de caso de uso não oferece detalhes que são necessários para um bom entendimento do negócio. Para que esses detalhes fiquem a vista, é utilizado a Descrição de Casos de Uso, que consiste em descrever textualmente os comportamentos de terminado caso de uso apresentando o seu fluxo principal, e o curso alternativo que pode ocorrer.

As associações entre Casos de Uso nos mostra o relacionamento entre ele e o ator ou entre os Casos de Uso entre si, sendo que pode haver um relacionamento de inclusão que significa que o caso de uso base incorpora explicitamente o comportamento de outro caso de uso; e de extensão onde o caso de uso base incorpora implicitamente o comportamento de um outro caso de uso em um local especificado.

Análise Orientada a Objetos

O objetivo da análise orientada a objetos é definir as classes e os relacionamentos e comportamentos associados a ela, que são relevantes para a solução do problema.

A popularidade da orientação a objetos fez surgir dezenas de métodos OO para análise e projeto. Cada um deles, introduz um processo para analisar um sistema, um conjunto de modelos que evoluem ao longo do processo e uma notação que permite ao engenheiro criar um modelo de maneira consistente.

A partir o levantamento de requisitos e a construção do diagrama de caso de uso e suas descrições, começamos a identificar as classes que é o ponto central do modelo orientado a objetos.

As classes que vão compor o Diagrama de Classes, apresentam o seu nome, atributos e operações, sendo este o modelo inicial do sistema que deverá ser cada vez mais detalhado daí em diante.

As classes são dispostas seguindo uma hierarquia que pode ser de generalização e especialização. Onde temos uma subclasse que deve ter uma relação de “é um tipo de” para uma superclasse; a subclasse deve suportar toda a funcionalidade de uma superclasse.