Como descrever casos de uso - Parte 4

Nosso blog está mudando de endereço. Acesse.


Durante a modelagem de casos de uso uma das coisas mais importantes é descrever o comportamento de cada caso de uso. Essa descrição é também chamada de Especificação de Caso de Uso.

O RUP define um template que indica os itens que devem compor a especificação. Esse template é bastante extenso, mas eu sempre o uso como base para sugerir um template mais simples e ágil....

Continue a leitura no nosso novo endereço do blog. 

Como elicitar Casos de Uso? Parte 3

Dando continuidade à sequência de posts sobre casos de uso, vou comentar agora sobre a importância da obtenção de valores agregados ao negócio na elicitação de casos de uso.

Um dos pontos mais críticos em uma gestão de requisitos com casos de uso é a correta elicitação dos casos de uso. Na hipótese disso não ser muito bem feito, trará conseqüências desastrosas à eficácia do projeto.

Um caso de uso pode ser identificado respondendo a seguinte pergunta feita a um usuário: O que você pretende obter usando o sistema? A resposta que ele dará é algo relacionado ao resultado de valor que ele espera obter ao usar o sistema. Na verdade, a modelagem de casos de uso é a arte de identificar valores que o sistema deve agregar ao negócio. Por isso quando estamos elicitando casos de uso, devemos estar muito atentos para que todos esses resultados de valor sejam obtidos. Nossa preocupação é fazer com que o conjunto dos casos de uso que modelarmos, entregue todos esses valores esperados. O escopo de cada caso de uso está fortemente associado à obtenção de valores agregados ao negócio.

Leia mais acessando nosso novo endereço:  

Treinamento em Análise-Design de Serviços com SOAML

Nosso blog está mudando de endereço. Acesse www.wm2info.com.br.

A Análise-Design é um disciplina da Engenharia de Software de fundamental importância para a elaboração da arquitetura da aplicação a ser desenvolvida, bem como para definir os modelos necessários que irão guiar todo o processo de implementação e implantação. Podemos dizer que se trata da “Planta Baixa” do sistema a ser desenvolvido.

Da mesma forma que a construção de uma casa, edifício ou qualquer tipo de edificação, necessita de um projeto arquitetônico e um projeto detalhado de construção, o software também necessita de um conjunto de modelos que são criados com uso de boas práticas de Análise-Design.

O conceito de Orientação a Serviços agrega valor à Análise-Design, trazendo uma capacidade maior de distribuir os Serviços em nuvens que podem estar cada vez mais espalhadas em provedores de Serviços especializados. Com essa realidade cada vez mais presente, profissionais de tecnologia precisam estar aptos a lidar com esta realidade e capazes de projetar sistemas e modelos de Serviços adequados a cada situação.

O curso iniciará com uma recapitulação dos conceitos de Análise-Design OO, UML e Modelagem de Processos de Negócio, assuntos que são pré-requisitos para a elicitação e especificação de Serviços com SOAML.

SOAML é uma extensão da UML, definida pela OMG – Object Management Group, usada na modelagem de Serviços em uma Arquitetura Orientada a Serviços (SOA).

O curso proverá conhecimentos sobre padrões e modelos necessários para compreender, identificar e produzir especificações de Serviços para o desenvolvimento de softwares em uma Arquitetura Orientada à Serviços.

Público Alvo
Analistas, arquitetos, desenvolvedores e líderes de projeto com formação e/ou experiência na área de Tecnologia da Informação e que desejam conhecer especialmente a Análise e Design de Web Services e a construção de Modelos de Serviços utilizados para viabilizar sua implementação.

Programa

• Revisão de conceitos sobre Análise e Design em Orientação a Objetos
• Revisão de conceitos sobre UML
• Fundamentos de SOA
• Conceitos Básicos sobre Processos de Negócio
• Padrões Fundamentais de Definição de Serviços
• Técnicas de Identificação Serviços Candidatos e Hierarquia de Serviços
• Orientação a Serviços e Separação de Interesses
• Princípios aplicados à modelagem de serviços
• Processo de Especificação e Modelagem de Serviços
• Camadas Lógicas de Abstração de Serviços e Classificação de Modelo de Serviços
• Tipos e Escopos Comuns de Granularidade
• Conceitos fundamentais de Web Services
• Protocolos fundamentais para utilização de Web Services
• Padrões de interoperabilidade adotados no mercado
• Estudo de Casos
• Exercício Prático

Ferramenta utilizada:

• Enterprise Architect (EA)

Data de Início

Trata-se de um curso sob demanda, ou seja, a data de início é definida quando o número de inscritos atingir o mínimo necessário para a formação da turma. A data prevista para início é: 17/03/2012 (17, 24, 31/03 e 14/04). Não haverá aula no dia 07/04 devido à semana santa. Esta data poderá ser alterada.

Carga horária

32 horas (4 sábados de 8 horas) de 09 a 18:00 horas com uma hora de intervalo para almoço.

Será oferecido dois coffeebreaks por sábado. Almoço e estacionamento serão de responsabilidade do aluno.

Local

Laboratório da Veris – IBTA do Grupo IBMEC. Av. Paulista, 302, (em frente a estação do metrô Brigadeiro); São Paulo – SP.

Professor

Gregório Momm

Com uma longa experiência no desenvolvi-mento de softwares, trabalhou em mais de 50 diferentes projetos em plataformas variadas desde dispositivos móveis, aplicações Web, sistemas em Mainframe e outros. Bacharel em Ciência da Computação e Desenvolvimen-to de Software, cursou Unicamp e Universi-dade Anhembi Morumbi, trabalhando na IBM desde o ano 2001, atualmente  Arquiteto de Software com atuação em diversos projetos que utilizam Arquitetura Orientada à Serviços.

Casos de Uso - Embora seja uma técnica muito utilizada, ainda é mal compreendida – Parte 1

Nosso blog está mudando de endereço. Acesse www.wm2info.com.br.

Estou apresentando o primeiro de uma série de cinco posts que estou escrevendo sobre o assunto Modelagem de Casos de Uso. Cada post irá abordar diferentes aspectos dessa técnica (Bittner, 2003; pag.9) tão utilizada, no mundo inteiro, na elicitação de requisitos de software.

O que me motivou escrever sobre esse assunto foi o fato de perceber uma grande carência de conhecimentos dos fundamentos teóricos que devem referenciar o trabalho dos Analistas de Negócio, Analistas de Requisitos, Analistas de Sistemas, Arquitetos de Software e principalmente dos Gerentes e Líderes de Projeto.

Em cada projeto que me envolvo como consultor, mentor ou coach, noto que os profissionais envolvidos na gestão de requisitos desconhecem os pilares que fundamentam a elicitação de requisitos de software. Heroicamente, eles usam conhecimentos obtidos com colegas que também aprenderam como outros colegas e assim por diante. Admiro a coragem desses profissionais, pois como bons brasileiros são versáteis e “se viram” fazendo o projeto andar. O problema é que o uso equivocado de técnicas pode causar graves danos na qualidade final do produto.

Cada vez mais me convenço de que Casos de Uso é uma excelente técnica que deve ser usada para a elicitação de requisitos de software. Infelizmente ela tem sido bastante mal interpretada pelos membros das equipes de projetos de desenvolvimento de software.

Aproveito a oportunidade para salientar que, com o advento do Use Case 2.0 apresentado recentemente por Ivar Jacobson (Jacobson, 2011), o pai dos casos de uso, poderemos seguramente continuar a usar casos de uso em projetos ágeis, pois, se descritos apropriadamente, se convertem em excelentes contextos para a elicitação de Estórias do Usuário, tão utilizadas em metodologias ágeis como o SCRUM e XP.  

Percebo que muitos gerentes de projetos, ou qualquer profissional associado ao planejamento de projetos de software têm usado casos de uso como um repositório para toda e qualquer especificação endereçada à equipe de construção de aplicações. Com isso obtemos casos de uso extremamente longos, aninhando vários outros artefatos de diferentes níveis de abstrações elevando desnecessariamente a complexidade, dificultado a comunicação e confundindo usuários e desenvolvedores.

Com isso perde-se muito tempo para produzir e validar todos esses artefatos e depois, um outro tempão para compreender o que foi escrito. Frequentemente esses artefatos apresentam problemas de completeza, ambigüidade, falta de clareza, levando o desenvolvedor a retornar aos analistas de negócio ou usuário para completar ou entender os requisitos descritos. Tudo isso leva a um desperdício de tempo onerando o projeto.

Casos de uso é um artefato de nível de abstração conceitual. Não é de implementação. Por isso não deveríamos associá-los a telas. Telas ou protótipos de telas devem estar associados a caso de uso, mas não o contrário. Telas implementam casos de uso e possuem uma forte rastreabilidade entre eles, mas isso não quer dizer que uma tela ou protótipo de tela deva compor a descrição de um caso de uso.

A descrição de casos de uso deve ser feita de forma altamente abstrata, sem nenhuma inferência em soluções de implementação. Dessa forma poderemos deixar os casos de uso independentes e totalmente livres do impacto das freqüentes alterações das interfaces gráficas do usuário. Imagine, cada alteração que tiver na tela, ter que alterar também o caso de uso. Isso é um absurdo, pois irá onerar desnecessariamente o projeto.

Caso de uso é algo bem mais simples do que parece. Para melhor explicar vou contar uma história que resume como e porque surgiu os casos de uso. Em 1979 Tom DeMarco escreveu o livro "Structured Analysis and System Specification" (Claudiomir, 1999) onde ele apresentou os princípios básicos da Análise Estruturada. Paralelamente Gane e Sarson se juntaram às idéias de Tom DeMarco e publicaram o famosíssimo livro “Análise Estrutura de Sistemas”, ainda hoje vendido nas principais livrarias do mundo inteiro. A principal ferramenta apresentada era o Diagrama de Fluxo de Dados (DFD), ainda muito utilizada, principalmente em projetos para alta plataforma.

Isso trouxe uma enorme evolução e padronização na forma de conceber um sistema de software. A intenção original era trazer o usuário para a equipe de projeto no papel de co-autor na concepção da aplicação. Infelizmente isso não ocorreu como se esperava, porque o DFD é uma técnica composta de muitos elementos e regras, tais como Entidades Externas, Funções, Fluxos de Dados, Depósito de Dados, um conjunto de Diagramas mostrando a Decomposição Funcional partindo do nível zero (frequentemente chamado de Diagrama de Contexto) até chegar nas primitivas funcionais que corresponderiam a programas ou módulos de programas a serem codificados em uma determinada linguagem, naquela época, o nosso velho e eficaz COBOL.

O problema é que o Usuário não estava preparado para tudo isso. O que ele queria (e continua querendo) é somente uma coisa: software funcionando para resolver o problema dele. Como eles eram, e continuam sendo, leigos em Engenharia de Software, isso tudo era muito complexo para eles. Por isso a intenção de ter o Usuário como co-autor ficou frustrada.

Contudo, a necessidade de envolver os usuários em projetos de software continuou aumentando, porque as necessidades dos negócios elevavam constantemente a complexidade das soluções de software. Foi então, que no início da década 90, Ivar Jacobson, um dos três amigos que criaram a UML, desenvolveu uma técnica chamada de Casos de Uso. Seu objetivo era voltar a conquistar o Usuário. Por isso ele criou uma forma de diagrama extremamente simples que qualquer pessoa pudesse entender e usar. Era tão simples que mais parecia um desenho feito por uma criança de quatro anos.

O diagrama de Casos de Uso possui somente três elementos: Ator (representado por um bonequinho), Caso de Uso (representado por uma elipse) e uma Associação entre eles (representada por um tracinho). Veja bem, aquele tracinho não é um fluxo de dados. É somente uma associação, ou seja, um Ator está associado a um Caso de Uso. Nada mais do que isso. Tem mais outra coisa extremamente importante: não tem decomposição funcional. Fica tudo em um único diagrama. Em sistemas muito grandes, com muitos casos de uso, você até pode quebrar um diagrama de casos de uso em outros pequenos diagramas, mas isso é só uma sub-divisão seguindo algum critério para não deixar o diagrama muito grande. Isso NÃO É decomposição funcional. Todos os casos de uso de todos os diagramas possuem absolutamente o mesmo nível de abstração.

Então, logo de cara, vamos aprender uma coisa. Um caso de uso não corresponde a uma função de um DFD. Por favor, se você quer aprender modelagem de Casos de Uso, esqueça DFD. São paradigmas totalmente diferentes. DFD é uma técnica usada no paradigma de Análise Estruturada. Caso de Uso é outra coisa. É uma técnica pertencente ao paradigma Orientado a Objetos.

Vou confessar uma coisa para vocês. No fim da década de 90, quando iniciei meus estudos e pesquisas sobre UML, devido ao fato de já ter usado muito DFD, senti dificuldades para usar o conceito de Casos de Uso porque, inconscientemente buscava fazer uma paridade de um para outro, ou seja, com funções de DFD. Até que um amigo me disse: “enquanto não tirar o “chapéu” da análise estruturada, você não irá conseguir aplicar corretamente os conceitos de casos de uso”. Fiz isso e deu certo. Foi aí que vi que deveria guardar o DFD numa “gaveta”. Veja bem, não é jogar fora. É guardar numa “gaveta” em algum lugar no seu cérebro. Isso quer dizer que você não irá usá-la em projetos OO. Mas toda a experiência (“a manha”) já obtida no relacionamento com Usuário é extremamente bem vinda.

Hoje, como professor, percebo isso muito explicitamente em sala de aula. Alunos que iniciaram suas carreiras usando o paradigma OO entendem e aplicam com muito mais facilidade do que experientes Analistas de Sistema Seniores, com vinte ou mais anos de experiência no paradigma Análise Estruturada. Realmente, os analistas seniores conseguem entender muito bem o conceito de casos de uso, mas sentem dificuldades na hora de aplicar a técnica. Neste caso, além do treinamento formal em sala de aula, se faz necessária a aplicação de um processo de mentoring para ajudar, de forma personalizada, o aluno a aplicar corretamente a técnica.

No próximo post irei comentar sobre os fundamentos teóricos que envolvem a Modelagem de Casos de Uso.

BIBLIOGRAFIA

- Bittner, K; et. al.; Use Case Modeling; Addison-Wesley; 2003.

- Jacobson, I., Spence, I., Bitnner, K.; Use Case 2.0 – The Guide to Succeeding with Use Cases; Ivan Jacobson International, Dez/2011.

- Selner, Claudiomir; Análise de Requisitos para sistemas de informações, utilizando as ferramentas da qualidade e processos de software; Dissertação submetida à Universidade Federal de Santa Catarina para obtenção do grau de Mestre em Engenharia; Florianópolis, Agosto/ 1999; obtido na internet em 20/01/2012;  http://www.eps.ufsc.br/disserta99/selner/cap3.html; 

O RUP não é uma metodologia.

Nosso blog está mudando de endereço. Acesse www.wm2info.com.br.

O assunto metodologia ágil tem sido foco de vários whitepapers e comentários em blogs, sites e revistas especializadas. Sempre que leio algo sobre isso, faz-me lembrar da antiga forma de desenvolver sistemas nas décadas de 70 e 80, época em que os sistemas eram mais simples, as equipes eram menores, a subcontratação de serviços de desenvolvimento ainda não era uma realidade, a preocupação com reutilização era ainda embrionária, a quantidade de sistemas em uma empresa era pequena e as mudanças de requisitos eram bem menores que as atuais.

Os aspectos relacionados à modelagem de software sempre foram foco de estudo e de incansável busca por melhoramentos. A prova disso se encontra na proliferação de novos paradigmas, técnicas de modelagem, padrões de arquitetura e de projeto, notações e ferramentas de suporte ao desenvolvimento. A UML tem se mostrado eficiente como uma notação em modelagem de software no mundo inteiro, porque oferece suporte a todo o ciclo de vida de um projeto, diferente dos antigos fluxogramas, DFD, DER, DHF e outros, que cobriam somente alguns trechos do processo deixando “vácuos” entre eles.

Os processos de software, popularmente conhecidos como metodologias de desenvolvimento de sistemas, também têm experimentado grandes evoluções. O modelo de processo seqüencial clássico, também chamado de “cascata” ou waterfall, não mais atende às exigências dos novos projetos de sistemas de software de grande porte e de elevado grau de complexidade. Esses sistemas são desenvolvidos para dar suporte a processos de negócio que são constantemente criados e modificados em busca da satisfação dos clientes, colocação de novos produtos e serviços no mercado, eficiência, agilidade e redução de custos buscando a obtenção de melhores resultados financeiros para os investidores. Tudo isso causa freqüentes modificações dos requisitos de software ainda durante o desenvolvimento do sistema, bem como a redução dos prazos para a entrega do produto final de software aos seus usuários. Por isso existe uma enorme necessidade de um processo de software que dê suporte às mudanças de requisitos e que agilize a produção e a entrega do software aos seus usuários.

O RUP se apresenta como uma proposta de solução para resolver esse problema. Contudo, devido às suas características bidimensionais além de ser incremental, iterativo, dirigido por casos de uso e centrado em arquitetura, ele tem sido muito mal interpretado pelos gerentes de projeto, analistas de sistemas, projetistas, arquitetos e implementadores de software. Sua imagem é de uma enorme e complexa metodologia, extremamente burocrática e, por isso, sem condições de solucionar o problema acima comentado. Essa imagem é uma conseqüência de interpretações equivocadas dos conceitos que suportam o RUP.

Entendo que a culpa desse equivoco de entendimento tem sido da própria Rational, atualmente da IBM, e de grande parte dos articulistas que escrevem sobre o RUP. Ele tem sido vendido e noticiado como um processo de software, ou seja, uma metodologia que as empresas devem usar em seus projetos de software. A verdade é que o RUP não é uma metodologia nem um processo de software. O RUP é um modelo de processo, ou seja, um framework (arcabouço) de boas práticas que podem ser adaptadas para uso em projetos de software.

A Object Management Group (OMG) desenvolveu uma arquitetura de processos formada por quatro níveis de abstrações, onde o nível mais alto é representado pelo Meta-Object Facility (MOF). O segundo nível, que é uma instância do MOF, referencia o Software Process Engineering Metamodel (SPEM), um metamodelo de processos de software incremental e iterativo. O terceiro nível trata de modelos de processos incrementais e iterativos instanciados a partir do SPEM, onde o RUP é um deles. Por isso os processos, atividades, artefatos, diretrizes e conceitos do RUP devem ser considerados como modelos a serem adaptados para a realidade de uma empresa ou especificamente para um projeto de software. Essa adaptação leva à criação do quarto e último nível de abstração, que trata do processo de software especificamente definido para um determinado projeto.

Conclui-se assim, que cada projeto deve ter seu próprio processo de software instanciado a partir do RUP. O próprio RUP, na disciplina Ambiente, sugere a elaboração um artefato chamado Caso de Desenvolvimento, ocasião em que o engenheiro de processo tem toda liberdade para definir o processo a ser seguido no projeto que ele irá gerenciar, ou seja, definir quais os artefatos que deverão ser produzidos no projeto.

Diante disso, a fama do RUP em ser uma metodologia burocrática é inadequada e injusta. Inadequada porque o RUP não é uma metodologia e, injusta, porque ele foi idealizado para ser customizado para projetos específicos, fato que demonstra sua elevada flexibilidade. É essa flexibilização que permite a configuração de um processo simples e ágil que dê suporte a projetos que necessitam de uma resposta mais rápida. Mas cuidado, essa configuração requer um profissional com senioridade em Engenharia de Software.

Entendo que um dos fatores que contribuem para essa fama é a sua interface com o usuário. O RUP é um sistema web que deve ser instalado na intranet da empresa. A elevadíssima quantidade de páginas cheias de hiperlinks oferece uma enorme quantidade de alternativas de navegação permitindo que usuários iniciantes venham a se perder. Em minhas palestras sobre o RUP, costumo dizer que ele deveria ter como símbolo uma bola, porque não tem começo nem fim. É como fazer compras em um supermercado. Você pode iniciar suas compras em qualquer lugar e tomar qualquer direcionamento. É totalmente ad hoc, permitindo que você possa iniciar sua leitura em qualquer ponto e tomar o caminho que desejar. Por isso, recomendo que as empresas que pretendem usar o RUP como modelo de processo devem ter engenheiros de software com total fluência no RUP para dar suporte aos gerentes no planejamento de seus projetos de software.

Algumas empresas procuram implantar modelos de processos derivados do RUP para serem usados em seus projetos. Isso é muito bom, porém perigoso. É bom porque permite tirar os excessos do RUP e propor cenários de desenvolvimento previamente configurados, constituídos por modelos de processos simplificados e customizados às idiossincrasias do ambiente de desenvolvimento da empresa. Cada cenário oferecerá uma alternativa de processo de software que deverá ser usado em uma determinada categoria de projetos. Depois da categorização do projeto o gerente terá um modelo de processo adequado para ser usado em seu projeto. Mas cuidado porque aí reside um perigo. A definição dos critérios de categorização poderá, sem querer, causar um retorno ao problema de burocratização do seu processo. E aí, não vale jogar a culpa no RUP. A culpa será sua.

Para concluir podemos dizer que o RUP não é uma metodologia. É um arcabouço de boas práticas que devem ser customizadas para aplicação específica em projetos de software, inclusive projetos ágeis, que possuem reduzidos prazos de entrega.

São Paulo, 15 de fevereiro de 2008.