UML - Unified Modeling Language - Requisitos, Classes e Objetos

Neste artigo vamos conhecer um pouco mais sobre análise de requisitos, classes e objetos em UML.

por Admilson Nogueira

Requisitos

Esta fase captura as intenções e necessidades dos usuários do sistema a ser desenvolvido através do uso de funções chamadas "use-cases". É a descrição das necessidades ou desejos de um determinado sistema .

O princípio básico da análise de requisitos é identificar e documentar o que é realmente necessário, desta forma comunicando a todos os envolvidos no projeto da forma mais clara possível, de maneira não-ambígua de modo que os riscos sejam identificados sem correr riscos de imprevistos.

Através do desenvolvimento de casos de uso (em UML chamamos de “use-cases”), as entidades externas ao sistema (em UML chamamos de "atores externos") que interagem e possuem interesse no sistema são modelados entre as funções que eles requerem, funções estas chamadas de "use-cases". Veja figura abaixo:

Os atores externos e os "use-cases" são modelados com relacionamentos que possuem comunicação associativa entre eles ou são desmembrados em hierarquia. Descrevemos um “use-case” através de um texto especificando os requisitos do ator externo que utilizará este “use-case”. Um “use-case” tanto pode depender de um ou mais “use-case” como pode ter seus dependentes. Através do diagrama de “use-cases” mostraremos aos atores externos (futuros usuários), e o que estes podem esperar do sistema.

A análise de requisitos também pode ser desenvolvida baseada em sistemas de negócios, e não apenas para sistemas de software, e os atores podem também ser sistemas ou outros softwares. Veja figura:

A fase de análise preocupa-se com as primeiras abstrações (classes e objetos) e mecanismos presentes no contexto do problema. Descrevemos as classes nos Diagramas de Classes e também para ajudar na descrição dos “use-cases”, podendo estas estar ligadas uma nas outras através de relacionamentos.

Nesta fase modelamos somente as classes que pertencem ao domínio principal do problema, ou seja, classes técnicas mais detalhadas não estarão neste diagrama.

O Projeto cria uma representação do domínio do problema do mundo real e leva-a a um domínio de solução que é o software.

Nesta fase partimos para as soluções técnicas, através dos resultados obtidos na fase da análise. Serão adicionadas novas classes para oferecer uma infra-estrutura técnica tais como: interface do usuário e periféricos, banco de dados, interação com outros sistemas, e outras mais. É feita uma junção das classes da fase da análise com as classes técnicas da nova infra-estrutura, podendo assim alterar tanto o domínio principal do problema quanto a infra-estrutura.

Com a elaboração do projeto obtemos detalhadamente as especificações (requisitos), para dar inicio a fase de programação.

Tenha sempre em mente que o importante é entender o Usuário.

Agora que você já tem uma pequena noção de uma parte dos Levantamentos de Requisitos , vamos abordar a prática das Notações. Você vai conhecer os símbolos usados na UML.

Classes

Definição

Uma Classe, em linguagens Orientadas a Objeto, é a possibilidade de combinar num único registro, campos de dados e campos que são funções para operar os campos de dados do registro.

Em outras palavras, as classes são os blocos de construções mais importantes de qualquer sistema orientado a objetos. Uma classe é uma descrição de um conjunto de objetos que compartilham os mesmo atributos, operações, relacionamentos e semântica. Podem ser implementadas em uma ou mais interfaces.

Todos os objetos são instâncias de classes, onde a classe descreve as propriedades e comportamentos daquele objeto.

Em UML as classes são representadas por um retângulo dividido em três compartimentos:

• Nome : que conterá apenas o nome da classe modelada;
• Atributos : que possuirá a relação de atributos que a classe possui em sua estrutura interna;
• Operações : que serão os métodos de manipulação de dados e de comunicação de uma classe com outras do sistema.

A sintaxe usada em cada um destes compartimentos é independente de qualquer linguagem de programação, embora podem ser usadas outras sintaxes como a do C++ e Java.

Existem outras particularidades ligadas as Classes em UML, mas deixemos isso para os artigos mais avançados.

Nomes

Todas as classes devem ter um nome que as diferencie das demais. Usamos uma seqüência de caracteres para identificá-las. Uma classe pode ter um nome simples, ou com caminho. O caminho identifica o pacote ao qual a classe pertence.

Atributos

Um atributo é uma propriedade de uma classe, que descreve um intervalo de valores que as instâncias da propriedade podem apresentar. Uma classe pode ter qualquer número de atributos ou nenhum. Um atributo representa o tipo de dados ou estados que cada item de uma classe pode assumir, são representados logo após o nome da classe.

Operações

As Operações são os processos que a classe pode realizar. As Operações correspondem claramente a métodos em uma classe. No nível de especificação, as operações correspondem a métodos públicos. Normalmente, você não mostra as operações que simplesmente manipulam atributos, porque elas podem ser freqüentemente inferidas. Entretanto, você poderá ter que identificar seu um dado atributo é somente para leitura (isto é, o seu valor nunca muda). No modelo de implementação, você também pode querer mostrar operações privativas (private) e protegidas (protected).

Uma classe pode ter várias operações ou até mesmo nenhuma, são representadas logo após os atributos.

Na Prática

Para que uma fase de programação possa ter um bom desempenho, necessitamos de um projeto bem elaborado, conseqüentemente converteremos as classes da fase do projeto para o código da linguagem orientada a objetos escolhida. Se o desenho foi elaborado corretamente e com detalhes suficientes, a tarefa de codificação é facilitada. A complexidade dessa conversão vai depender da capacidade da linguagem escolhida, no entanto esta pode tornar-se fácil ou difícil de se realizar.

Em UML durante a elaboração dos modelos de análise e projeto, devemos evitar traduzi-los em códigos. Cabendo esta tarefa à fase de programação.

Agora que você já tem uma pequena noção de uma parte das Classes da UML, vamos abordar os Objetos, que nada mais são do que as Classes em ação.

Objetos

Definição

Os objetos são elementos que podemos manipular, acompanhar seu comportamento, criar, interagir com ele, ou até destrui-lo. Um objeto pode existir no mundo real ou pode ser uma derivação de estudos da estrutura e comportamento de outros objetos do mundo real. Corresponde a qualquer coisa que tenha algum significado para uma dada aplicação. Por exemplo, uma máquina, uma organização, ou negócio.

Um objeto é simplesmente alguma coisa que faz sentido no contexto de uma aplicação. Objeto é uma entidade independente, assíncrona e concorrente, armazena dados, encapsula serviços, troca mensagens com outros objetos, e é modelado para executar as funções finais do sistema.

Abstração de um Objeto

Abstração é o princípio de ignorar os aspectos de um assunto não relevante para o propósito em questão, tornando possível uma concentração maior nos assuntos principais. Consiste na seleção que o analista faz de alguns aspectos, ignorando outros. Existem duas formas de abstração, de Procedimentos e de Dados.

Abstração de Procedimentos

Princípio de que qualquer operação com um efeito bem definido pode ser tratada por seus usuários como uma entidade única, mesmo que a operação seja realmente conseguida através de alguma seqüência de operações de nível mais baixo.

Abstração de dados

Consiste em definir um tipo de dado conforme as operações aplicáveis aos objetos deste tipo. Porém, estes objetos só podem ser modificados e observados através destas operações.

Encapsulamento

Encapsular é omitir informações pelo princípio de que uma determinada entidade esconde informações as quais são necessárias apenas à mesma. É fundamental que o objeto proteja seus dados, não permitindo que o usuário do objeto os acesse diretamente. Mas sim através de métodos se houver necessidade.

Polimorfismo

É o conceito usado em linguagens de programação orientada a objetos para denotar a característica de que a linguagem suporta a utilização do mesmo identificador (o mesmo nome) para métodos de classes diferentes.

Um conceito em teoria de tipo no qual um nome (como uma declaração de variável) pode denotar objetos de muitas subclasses diferentes que são relacionadas por alguma superclasse comum, assim, qualquer objeto denotado por esse nome tem a capacidade de responder a algum conjunto comum de operações de modos diferentes.

Objetos na UML

Em UML um objeto é mostrado como uma classe só que seu nome é sublinhado, e o nome do objeto pode ser mostrado opcionalmente precedido do nome da classe.

Precursores da analise orientada a objeto, defendiam que devíamos estruturar programas de computador de acordo com o problema a ser resolvido. O termo Orientação a Objetos sugere abstrações do mundo real e trechos de programas de computador, ou objeto.

Um grande fator da orientação a objetos é a reusabilidade. Estamos reutilizando códigos de programas desde o início da computação. As técnicas de orientação a objetos nos permitem muito mais que a reutilização de códigos, podemos reutilizar requisitos, análise, projeto, planejamento de testes, interfaces de usuário e arquiteturas, ou seja todos os componentes de engenharia de software podem ser encapsulados como reutilizáveis.

Análise Orientada a Objetos

Análise é o estudo de um problema, antes de qualquer ação.

Análise é o estudo do domínio de um problema que leva a uma especificação de comportamentos observáveis externamente. É uma declaração completa, consistente e possível do que é necessário, um conjunto de características operacionais quantificadas e funcionais.

Analisar é obter as necessidades de um sistema e o que este precisa ser desenvolvido para satisfazer as necessidades do usuário. Analisar não é definir como o sistema será desenvolvido, mas sim investigar o problema

A AOO tem dois propósitos. Primeiramente formalizar uma “visão” do mundo real dentro do qual o sistema será desenvolvido, estabelecendo os objetos que servirão como principais estruturas organizacionais do sistema de software e também as que o mundo real impõe. Em segundo lugar, a AOO formaliza a colaboração de um dado conjunto de objetos na execução do trabalho do sistema de software que está sendo especificado. Esta formalização representa como cada objeto se comunica com os demais.

O Projeto Orientado a Objetos (PjOO) é visto como o processo de especificação das partes da construção, ou seja, instruções, guias, recomendações, estipulações, qualificações, regras, etc.. Utilizamos estes processos para implementar um sistema em um ambiente específico, em busca da solução do problema

Durante a PjOO é dado ênfase na elaboração dos elementos lógicos do software. Sendo implementados em uma linguagem de programação orientada a objetos, os quais possuem atributos e métodos.