Uma vez estudado o comportamento do sistema, tem-se uma base para a definição das operações das classes que compõem o sistema. Operações correspondem a serviços que podem ser solicitados aos objetos de uma classe e são apresentadas na seção inferior do símbolo de classe, com a seguinte sintaxe23 para a sua assinatura (BOOCH; RUMBAUGH; JACOBSON, 2006):
visibilidade nome(lista_de_parâmetros): tipo_de_retorno
A visibilidade de uma operação indica em que situações ela é visível por outras classes, podendo uma operação ser pública, protegida, privada e de pacote, da mesma forma que atributos (ver Seção 6.2.1). A informação de visibilidade é inerente à fase de projeto e não deve ser expressa em um modelo conceitual.
Para nomear uma operação, sugere-se o uso de um verbo no infinitivo, o qual pode ser combinado com complementos, omitindo-se preposições. A exceção fica por conta de operações com retorno booleano, para as quais se sugere usar um nome que dê uma noção de
23 A UML admite outras informações na assinatura de uma operação. Entretanto, essas são as notações mais comumente utilizadas.
uma pergunta sendo feita. O nome da operação deve ser iniciado com letra minúscula, enquanto os nomes dos complementos devem iniciar com letras maiúsculas, sem dar um espaço em relação à palavra anterior. Acentos não devem ser utilizados. Ex.: calcularValor, emAtraso.
Na assinatura de uma operação, podem ser indicados zero ou mais parâmetros separados por vírgula, cada um deles com a sintaxe abaixo24, onde nome_parâmetro é o nome para referenciar o parâmetro, tipo é seu tipo de dados ou classe, e valor_padrão é o valor que será assumido se um valor não for informado.
nome_parâmetro: tipo [= valor_padrão]
O tipo_de_retorno indica a classe ou o tipo de dado do valor retornado pela operação, o qual pode ser uma classe, um tipo de dado primitivo ou um tipo de dado específico de domínio. Caso uma operação não tenha retorno, nada é especificado.
Conforme discutido anteriormente, há operações, ditas básicas, que simplesmente manipulam atributos e associações, criam ou destroem objetos. Essas operações não são representadas nos diagramas de classes, nem especificadas e documentadas no Dicionário de Projeto, já que podem ser deduzidas do modelo conceitual estrutural. As demais operações devem ser descritas no Dicionário de Projeto, dando uma descrição sucinta de seu propósito.
Referências do Capítulo
BLAHA, M., RUMBAUGH, J., Modelagem e Projetos Baseados em Objetos com UML 2, Elsevier, 2006.
BOOCH, G., RUMBAUGH, J., JACOBSON, I., UML Guia do Usuário, 2a edição, Elsevier Editora, 2006.
OLIVÉ, A., Conceptual Modeling of Information Systems, Springer, 2007.
WAZLAWICK, R.S., Análise e Projeto de Sistemas de Informação Orientados a Objetos, Elsevier, 2004.
Capítulo 8 – Qualidade e Agilidade em Requisitos
Durante o processo de Engenharia de Requisitos, diversos documentos e modelos podem ser elaborados. Durante o levantamento de requisitos, requisitos de cliente são capturados em um Documento de Requisitos. Na fase de análise, esses requisitos são especificados usando diagramas diversos organizados em dois modelos principais: o modelo estrutural e o modelo comportamental. O modelo conceitual estrutural de um sistema tem por objetivo descrever as informações que esse sistema deve representar e gerenciar. O modelo comportamental, por sua vez, provê uma visão ampla do comportamento do sistema.
No que tange à modelagem do comportamento de um sistema, em um nível superior, os diagramas de casos de uso proveem uma visão externa da funcionalidade do sistema e dos atores nela envolvidos. O comportamento dos casos de uso é elaborado por meio de descrições de casos de uso. Essas descrições podem ser refinadas por meio de diagramas de atividade ou de sequência. Os diagramas de sequência tipicamente mostram visões parciais. Eles, geralmente, são desenvolvidos apenas para fluxos de eventos principais ou são desenvolvidos um diagrama de sequência para o fluxo principal de eventos e diagramas adicionais para os fluxos de exceção e variantes. Diagramas de atividade permitem consolidar todo esse comportamento em um único diagrama, documentando ramificações, bifurcações e uniões do fluxo de controle. Diagramas de sequência são bons para mostrar colaborações entre objetos em um caso de uso. Já os diagramas de atividade são úteis para focalizar as atividades de um processo complexo. Contudo, esses dois tipos de diagramas não são apropriados para observar o comportamento de um objeto isolado ao longo de vários casos de uso. Para tal, são utilizados diagramas de gráfico de estados.
Neste contexto, uma questão importante precisa ser tratada: como fazer a engenharia dos requisitos de um sistema com qualidade, mas ao mesmo tempo de maneira ágil, sem despender tempo elaborando diagramas que acrescentam pouco valor ao projeto? Não se deve perder de vista que o propósito da modelagem é ajudar a entender o problema de modo que se possa produzir um sistema que atenda às necessidades do usuário. Produzir artefatos desnecessários transforma o trabalho de Engenharia de Software em “burocracia de software”. Para tratar essa questão, primeiro deve-se considerar a ótica da qualidade. Sob esse ponto de vista, é fundamental garantir consistência entre os diversos artefatos produzidos. Os diversos documentos e modelos proveem diferentes visões de um mesmo sistema e, portanto, devem estar compatíveis entre si. É importante observar que os modelos produzidos envolvem conceitos comuns, dentre eles classes, objetos e operações, e que é essencial manter as informações rastreáveis. Ambos os modelos, estrutural e comportamental, são necessários para um completo entendimento de um problema, embora a importância de cada um dos diagramas envolvidos varie de projeto para projeto e em função do tipo de aplicação a ser desenvolvida. Esses modelos se unem para dar forma às classes com atributos, associações e operações, que serão a base para o projeto e a implementação. Em especial, as operações envolvem dados (objeto destino, argumentos, variáveis e retorno), controle (sequência) e interações (mensagens e chamadas). Assim, para uma completa especificação das classes, o que envolve a
especificação de suas operações, são necessários os modelos estrutural e comportamental. Além disso, é necessário compará-los para garantir que não há inconsistências entre eles (BLAHA; RUMBAUGH, 2006). Para apoiar a verificação da consistência, técnicas de leitura de modelos de análise podem ser aplicadas. Algumas dessas técnicas são discutidas na Seção 8.1.
Do ponto de vista de agilidade no processo de Engenharia de Requisitos, merece destaque a modelagem ágil. A modelagem ágil provê uma série de princípios e valores que podem ser aplicados para nortear a decisão de quais diagramas produzir, de modo que o esforço despendido na análise de requisitos seja compensador. A modelagem ágil é discutida na Seção 8.2.
Por fim, visando tanto à qualidade quanto a agilidade, podem ser aplicadas técnicas de reutilização de requisitos. A reutilização tende a proporcionar qualidade, uma vez que os requisitos, modelos ou outros artefatos reutilizados já foram avaliados em outros contextos e, por conseguinte, tendem a prover soluções já avaliadas. Do ponto de vista da agilidade, ao se reutilizar algum artefato da Engenharia de Requisitos, espera-se que haja um aumento da produtividade, uma vez que não se está partindo do zero. A reutilização na Engenharia de Requisitos é discutida na Seção 8.3.