quarta-feira, 29 de fevereiro de 2012

Estamos mudando para outro endereço.

Prezado leitor.

Estamos mudando para um outro endereço:

www.wm2info.com.br
ou
www.evandrionico.com.br

Aguardo você no nosso site.

Abraço

Evandro Moreira Pinto

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.

terça-feira, 28 de fevereiro de 2012

WM2info lança curso de 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.

A WM2info está lançando um curso de Análise-Design de Serviços com uso de SOAML. Será feita 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 o curso. SOAML é uma extensão da UML, definida pela OMG – Object Management Group que é usada na modelagem de Serviços em uma Arquitetura Orientada a Serviços (SOA).

Para ministrar esse curso, convidamos o Gregório Momm, Arquiteto de Software e Arquiteto Empresarial da IBM, possuidor de larga experiência com mais de 50 (cinqüenta) projetos que utilizam Arquitetura Orientada a Serviços (SOA) e plataformas variadas, tais como dispositivos móveis, aplicações WEB, Mainframe e outros.

Gregório Momm também é Professor em cursos de Pós-Graduação da VERIS – IBTA do Grupo IBEC, palestrante e instrutor em Arquiteturas de Software e Empresarial.

Seja bem vindo Gregório.


quarta-feira, 1 de fevereiro de 2012

Que é Caso de Uso? - Parte 2

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

Dando prosseguimento à sequência de publicações que estou fazendo sobre Requisitos de Software, pretendo nesta segunda parte tratar do assunto Caso de Uso, porque é uma ferramenta que tem sido usada em todo o mundo. Corretamente usada, ou não, mas tem sido de enorme valia para projetos de desenvolvimento de sistemas de grande porte e de elevado grau de complexidade para alta e baixa plataformas.

Afinal de contas, o que é Caso de Uso? Existem algumas descrições que busquei na literatura para deixar claro e de forma inequívoca seu significado. Foram obtidas de autores de renome e fontes de aceitação internacional.

• A OMG – Object Management Group, conforme a UML Superstructure Specification, v2.0, Casos de Uso são meios para a especificação de usos necessários de um sistema. Normalmente, eles são usados para capturar os requisitos de um sistema, isto é, o que um sistema é suposto fazer. Observe que a OMG aborda o aspecto voltado para a captura de requisitos de software.

• Kurt Bittner no seu livro “Use Case Modeling”, afirma que Caso de Uso é uma técnica poderosa de modelagem de requisitos. Note que o autor salienta mais uma faceta do Caso de Uso, ou seja é uma técnica que pode ser usada na captura de requisitos de software.

• O RUP, por que vez, classifica Caso de Uso como um artefato. Neste ponto de vista o Caso de Uso é apresentado como um produto de trabalho que possui um ciclo de vida composto de fases que inicia na sua elicitação e termina na forma de um artefato implementado, testado e entregue ao usuário para uso operacional. Deve ser gerenciado como um importante Item de Configuração.

• O RUP acrescenta ainda um outro conceito, que descreve um conjunto de instâncias formadas por sequências de ações realizadas pelo sistema para produzir um resultado de valor observável pelo ator. São interações formando um diálogo entre o Usuário e o Sistema. Essa é a forma mais popular de entendimento do que significa Casos de Uso. Esse diálogo conta uma Estória de relacionamento entre o Usuário e o Sistema. Guarde esse termo “Estória”, pois iremos usá-la posteriormente nas próximas publicações que farei.

• Cockburn, no seu livro “Escrevendo Casos de Uso Eficazes” afirma que um Caso de Uso captura um contrato entre os stakeholders de um sistema sobre seu comportamento. É interessante notar que, usando Casos de Uso, podemos discutir soluções sem necessitar entrar em detalhes de implementação. Particularmente acho isso sensacional, porque nos permite concentrar nossa atenção na obtenção do valor esperado pelo usuário. Nesta ocasião, não estamos preocupados com telas e qualquer tipo de solução de interface gráfica. Estamos preocupados na eficácia do projeto, ou seja, em produzir o resultado de valor do ponto de vista do negócio.

• Cockburn afirma ainda que “casos de uso não especificam interfaces externas, formatos de dados, regras de negócio e fórmulas complexas. Eles constituem somente uma fração (talvez um terço) de todos os requisitos que você precisa coletar – uma fração muito importante, no entanto, uma fração”. Acho essa definição sensacional porque simplifica a especificação dos Casos de Uso, não descrevendo esses elementos (interfaces gráficas, tipos de dados, requisitos não-funcionais, regras de negócio, etc.). As Especificações de Casos de Uso referenciam esses elementos, mas não os descrevem.

Todas as definições acima listadas podem ser resumidas da seguinte forma sobre Casos de Uso:
• É uma técnica usada para a captura de requisitos do sistema.
• É um artefato que deve ser gerenciado como um item de configuração.
• Descreve interações entre o Usuário e o Sistema.
• Descrevem “cláusulas contratuais” entre o usuário e o projeto de desenvolvimento.
• Sua especificação não envolve a descrição de interfaces do usuário, interfaces com outros sistemas, tipos de dados, requisitos não-funcionais, fórmulas complexas e regras de negócio.

Percebo muito claramente os seguintes problemas na Modelagem de Casos de Uso.

1. Os templates usados na descrição dos casos de uso possuem itens desnecessários e contribuem fortemente para que as especificações sejam “gordas”. Noto que alguns analistas de qualidade dão muita atenção à forma, ou seja, à qualidade que eu, evandrionicamente, chamo de “qualidade cosmética”. Esquecem da essência do caso de uso, a qual é a produção do resultado de valor esperado pelo usuário (ainda vou falar muito sobre isso nos próximos posts). A Gestão da Qualidade deve se preocupar com o conteúdo, garantindo que o conjunto dos Casos de Uso entregará os valores esperados pelos stakeholders. A palavra chave é “Valor”. Perde-se muito tempo e esforço no preenchimento obrigatório de campos. Já vi templates que obrigam o analista a justificar porque não está preenchendo um determinado campo que é considerado obrigatório, fazendo com que seja gasto um tempo valioso na tentativa de dar a justificativa exigida pela “qualidade”. Isso é um absurdo. É por isso que eu odeio templates. Veja uma crônica que postei algum tempo atrás sobre esse assunto.

2. Tenho percebido que interfaces gráficas (telas), produzidas a partir de especificações detalhadas de Casos de Uso, são modificadas quando apresentadas ao Usuário para validação. É válido notar que a descrição (detalhada) desses casos de uso já tinha sido validada pelo próprio Usuário. Isso mostra que o detalhamento das interações Usuário X Sistema na especificação de casos de uso, nem sempre tem sido eficaz, porque não é visual. Um protótipo de tala (que é visual) é extremamente mais eficaz do que um texto, por mais detalhado que seja. Por isso, recomendo fortemente que não gastem esforços e tempo no detalhamento das interações Usuário X Sistema. A especificação dos Casos de Uso deverá descrever o essencial, o suficiente para dar a percepção de que o produto de valor esperado pelo Usuário será entregue na ocasião em que ele executar o Caso de Uso. Tenho aplicado essa abordagem em vários projetos e obtido agilidade e melhoramento nas comunicações com os Usuários, Web Designers, Arquitetos, Projetistas e Desenvolvedores. Nos treinamentos que ministramos abordamos largamente todos esses aspectos.

3. A inserção de soluções de tecnologia na especificação de Casos de Uso traz problemas de sustentabilidade. Em outras palavras, os casos de uso, por si só, não se sustentam porque quando chegam na fase de design, frequentemente a tecnologia especificada no Caso de Uso é incompatível com os padrões gráficos ou padrões de navegação usados no projeto. Ocorre, nesta ocasião, um conflito. O que deve prevalecer? O que está especificado no Caso de Uso ou que já está padronizado e combinado com a Empresa contratante do projeto? Certamente, o que irá prevalecer é o padrão que foi definido pelos Web Designers e Arquitetos em conjunto com a equipe técnica da empresa contratante. Esses detalhes de implementação não são de conhecimento dos Analistas de Negócio. Por isso os Casos de Uso precisarão ser alterados para ficar corretos. Isso consumirá recursos, tempo, elevando o custo e reduzindo a produtividade, que é tudo que não queremos. É por isso que muita gente por aí, ingenuamente, joga a culpa nos Casos de Uso. A culpa não está na técnica, e sim naquele que usou erroneamente a técnica.

4. A UML é uma notação que possui itens de estrutura, de comportamento, de agrupamento e de anotações. Tenho observado que profissionais com pouco conhecimento em UML, tendem a inserir na especificação de Casos de Uso, todos esses itens que serão definidos ao longo do ciclo de vida do projeto. Isso eleva desnecessariamente a complexidade do Caso de Uso, além de não resolver o problema de comunicação com a equipe de desenvolvimento, porque geralmente esses elementos adicionais são incompletos e descritos de forma ambígua e inconsistente. Percebi que isso ocorre porque o RUP diz que o Modelo de Casos de Uso influencia na elaboração de todos os demais modelos desenvolvidos (quando é desenvolvido) ao longo do projeto. O RUP está correto, mas isso não significa que elementos desses modelos devam constar da especificação dos Casos de Uso. Modelo de Caso de Uso é uma coisa, Modelo de Design é outra coisa, Modelo de Implementação também é outra coisa, e assim por diante. Esses modelos possuem elementos que realizam os Casos de Uso, mas isso não significa que fazem parte da especificação dos Casos de Uso. Lembrem-se do que Cockburn afirmou (veja acima) que Casos de Uso capturam somente um terço dos requisitos de um sistema. Os demais requisitos são capturados através de outras técnicas e artefatos. Casos de uso não é uma panacéia que veio para resolver todos os problemas da Engenharia de Software. É simplesmente um item de um dos 13 (treze) diagramas oferecidos pela UML.

Conclusão.
• A agilidade em um projeto é obtida, não na pressa, mas nas mínimas coisas, ou seja, na forma que os artefatos são produzidos e principalmente na comunicação. Lembrem-se sempre disso, a comunicação é um dos maiores pontos de atenção de um projeto, pois é fonte de muitos riscos.
• Nunca misture elementos de diferentes níveis de abstração em um único artefato. Por exemplo: Não insira soluções de tecnologia em um documento que deveria abordar aspectos conceituais. Soluções de tecnologia pertencem ao nível de abstração de implementação. Casos de Uso pertencem ao nível de abstração conceitual. É como óleo e água. Não se misturam.
• Caso de uso é uma ferramenta gerencial e operacional. Ela é excelente para o Gerenciamento de Escopo de projetos de software. Com uso do conceito de rastreabilidade, poderemos facilmente gerenciar mudanças de requisitos, tão frequentes nos projetos que participamos.
• Casos de Uso permitem a captura de requisitos. Isso não quer dizer que todos os requisitos capturados são descritos na Especificação dos Casos de Uso. Existem artefatos apropriados para cada tipo de requisito, regra de negócio, estrutura de dados, interfaces gráficas, etc.
• O objetivo da Modelagem de Casos de Uso não é definir as interfaces gráficas e sim definir os valores que o sistema irá produzir para o negócio. Esta é a essência da modelagem de casos de uso. Um bom Modelo de Casos de Uso se converte em um guia para a elaboração do Modelo de Design, Modelo de Implementação, Modelo de Implantação (deploy) e Modelo de Processos da aplicação. O conjunto desses modelos forma o Modelo de Visões Arquiteturais 4+1, que é o cerne da arquitetura de uma aplicação.
• Para concluir gostaria de deixar a seguinte mensagem: “Tudo que for fazer, faça-o com agilidade. Agilidade não é fazer as coisas apressadamente. Agilidade é fazer somente as coisas essenciais”.

BIBLIOGRAFIA.
1. Bittner, K; et. al.; Use Case Modeling; Addison-Wesley; 2003.
2. Jacobson, I., Spence, I., Bitnner, K.; Use Case 2.0 – The Guide to Succeeding with Use Cases; Ivan Jacobson International, Dez/2011.
3. OMG – Object Management Group; UML Superstructure Specification, v2.0.
4. Cockburn, A.; Escrevendo Casos de Uso Eficazes. Bookman, 2001.
5. BOOCH, G.; et al.; UML Guia do Usuário; Editora Campus; 2005.
6. RUP – Rational Unified Process. Versão 2002.