DIAGRAMA DE MÁQUINA DE ESTADOS

O Diagrama de máquina de estados tem por objetivo descrever o comportamento dos estados que objetos podem assumir durante sua existência.

Como assim ?
Na prática serve para documentar os diversos "ESTADOS" que qualificam algum STATUS de alguma coisa, seguem alguns exemplos:
- "Status do cliente" - Cliente Ativo; Cliente Bloqueado - podem ser estados do CLIENTE;
- "Status da Compra" - Pedido Aguardando Fechamento; Pedido Fechado - poderiam ser estados da COMPRA;
- "Status do Caixa" - Caixa Aberto; Caixa Fechado; Caixa Conferido pelo escritório; Caixa Reaberto - podem ser estados do CAIXA;
- "Status do Usuário"- Ativo; Cancelado; Logado; Inválido - podem ser estados do USUÁRIO.

Notação
Um estado no diagrama é representado por um retângulo com cantos arredondados. Pode possui mais de um compartimento separado por um traço, sendo o primeiro compartimento o nome ou a repsentação do estado:



o Segundo compartimento (opcional) identifica as "atividades internas" que descutiremos melhor depois:



O Estado inicial e o final são representados respectivamente pelos símbolos:



TRANSIÇÕES

As transiçoes dos estados são representadas por setas, veja como fica a representação de um diagrama de estado simples:




ENTERPRISE ARCHITECH

O EA tem suporte para esse diagrama, caso não esteja aparecendo o Toolbox "STATE" com os objetos específicos do diagrama de máquina de estados, vá na tela principal do EA verifique em "Manage My Profile..." se na opção "By Role" está selecionado "Show All"

Agora basta criar um novo Diagrama do tipo "State Machine" (Behavior) e arrastar os objetos.


TEM MAIS...

Esse diagrama tem muitas outras características mas achamos melhor deixar para comentar depois (como por exemplo o compartimento das "atividades internas"). Por enquanto, quem já conseguiu criar casos de uso no E.A. já pode tentar dar mais um passo e explorar esse Diagrama de Máquina de Estados, e se alguem descobrir alguma curiosidade, vamos conversar.....

INCLUDE OU EXTEND

O QUE SÃO ?
- Relacioamentos entre casos de uso. As definições são muito parecidas a príncipio e podem causar alguma confusão. Particularmente, eu não havia compreendido a diferença entre eles.No úlitmo livro que estou lendo a autora define :

EXTEND: indica que um caso de uso terá seu procedimento ACRESCIDO de outro caso de uso;
INCLUDE: indica que um caso de uso terá seu procedimento COPIADO no outro caso de uso;

ACRESCIDO, COPIADO - isso pode gerar certa dúvida para decidir qual devemos usar, mesmo porque as duas definições parecem ser a mesma coisa. Eu achei meio confuso, mas adotei como critério diferenciador os conceitos desse último livro que detalho a seguir:

QUAL A DIFERENÇA ?
INCLUDE
- Na versão da UML 2.0,o INCLUDE substituiu o USE, que era utilizado na UML versao 1.2
O INCLUDE é usado para relacionar dois casos e uso, informando que um deles terá seu procedimento "incluído no outro", de forma incondicional, ou seja vai acontecer. Por exemplo:

" CASO DE USO MATRICULAR ALUNO
1. O aluno digita sua matrícula. O sistema deverá verificar se a matrícula é válida. - Include (validar matrícula)
2. ...."

No exemplo, o caso de uso VALIDAR MATRÍCULA está incluído no caso de uso MATRICULAR ALUNO, ou seja em determinado momento vai acontecer VALIDAR MATRÍCULA...

EXTEND
Eu achei que o EXTEND se parece bastante com o INCLUDE. Mas ele "extende" um caso de uso, PODENDO ocorrer em um determinado ponto (cenário). Por exemplo:"

"CASO DE USO EFETUAR PAGAMENTO
4....
5.Escolher forma de Pagamento.
5.1 Se cliente VIP, calcular desconto especial. EXTEND (desconto cliente VIP)
6....

Veja que o caso de uso DESCONTO CLIENTE VIP só ocorre se o Cliente for VIP, não ocorrendo incondicionalmente como o INCLUDE.

QUANDO USAR ?
INCLUDE : Quando você perceber que um determinado trecho do caso de uso, poderá ser utilizados em mais de um caso de uso.
EXTEND: Idem ao INCLUDE com uma diferença: deverá ocorrer de forma condicional.

Capitulo 3 Caso de Uso

O Caso de Uso é a parte mais importante da construção de um software orientado a objetos usando a UML, sendo, talvez, o único instrumento que acompanha um software do seu início até a sua conclusão.
O QUE É UM CASO DE USO ?
Um caso de uso pode ser explicado como uma MACROATIVIDADE que encerra diversas tarefas ou atividades, ou uma representação descrita das varias ações para a realização dessa MACROATIVIDADE.
NOTA: No meu ver, o caso de uso difere bastante da lista de eventos da análise essencial porque não impõe tantas regras de "formatação". O Caso de uso tende a ser mais simples por ser uma descrição como um passo a passo da atividade a ser descrita. Além disso o seu formato pode ser adaptado de acordo com a necessiade da empresa que está desenvolvendo o software. Apesar de seguir um padrão, existem vários modelos de estrutura para a descrição de Casos de Uso, por exemplo: Uns apresentam uma estrutura com pré-requisitos, outros com estrutura mais simples, enfim o importante é adotarmos um padrão para escrever um caso de uso e acho que a ajuda de todos seria importante para a criação dessa estrutura . . .Mais abaixo veremos a estrutura sugerida pelo autor do livro.

QUANTO um caso de uso deve ser escrito?
Um caso de uso deve ser bastante detalhado. Na orientação a objetos usamos a técnica da ABSTRAÇÃO, que é:
"Princípio de ignorar os aspectos de um assunto, não relevantes para o propósito em questão, tomando possível uma concentração maior nos assutnos principais".
Em resumo, um caso de uso dave descrever os passos da atividade sem se tornar "massante" mas que possibilite a qualquer um entender esses passos.

Analista de Negócio
Esse é o responsável por extrair, ou definir, os casos de usos. Para o analista só existem duas formas de extrair esse casos de uso: OBSERVAÇÃO ou ENTREVISTA, sendo esta última a forma mais comum de definir os casos de uso.
Não vou descrever mais sobre o Analista de Negócio, porque todos nós temos essa capacidade de analisar a melhor solução para o negócio, em razão da experiência em desenvolvimento de software, o que não temos é a capacidade de gerar documentos nesse padrão e acho que é nisso que devemos manter o foco.....

Como extrair um Caso de Uso?
Segue abaixo a sugestão do autor, em cada livro que lemos temos uma sugestão diferente, porque o formato deve atender às necessidades do grupo de desenvolvedores e portanto é definida por eles:

Nome do Caso de Uso - Verbo no infinitivo;
Breve descrição - Assunto tratado naquele caso de uso;
Pré-Condição - Caso exista, deve ser relatado o que provoca o caso de uso;
Atores - Pessoas, sistemas, etc... que estejam envolvidos no caso de uso;
Cenários principais - São descritas as tarefas.
Requisitos Especiais - Descrições que não cabem nas secções anteriores, como: "Todos os cálculos envolvidos devem ter precisão de 4 casas decimais" ou "Esta consulta deve ser bem rápida, levando no máximo 4 segundos . . ."
Dados - Os atributos descritos no casod e uso, algo que possa pertencer a algum objeto , isso ajudará a descrever as classes.
Observações - Qualquer lembrete referente ao caso de uso, como por exemplo: "Existe um formulário padronizado para....."
IMPORTANTE: para um detalhamento razoável, podemos usar as perguntas: "O que é? Para quê? ou Por quê? Como?" com a finalidade que independente do conhecimento de quem está lendo não sejam geradas dúvidas. Não faz sentido um caso de uso em que alguem tem se voltar pra quem escrever e perguntar "O que voce quis dizer com ......?" ou "Quais são os documentos no cenário: Cliente informa seus dados ?"....
Os cenário principais não prevêem exceções ou seja, deve ser descrito o caminho no "melhor caso" ou no "caso de sucesso". Para as exceções existem os cenários alternativos.....



PARA UM EXEMPLO DE UM CASO DE USO
O marcelo já fez uso da ferramenta Enterprise Architec e gerou uma documentação que encontra-se no recurso M:/Atualizacao/index.htm que se refere ao nosso sistema de atualizações.

DIAGRAMA DE CASO DE USO
Antes de descrever os "cenários" (passos) de um caso de uso, é interessante definir quais casos de uso participam de um evento para montarmos o DIAGRAMA DE CASO DE USO, voltando ao livro veremos o exemplo: ao pensar no caso de uso Locar DVD, podermos enxergar mais alguns casos de uso: "Devolução" e "Entregar DVD Locado". Cada um desses três casos de uso terão descrições passo a passo (cenários). Mas já podemos montar um diagrama:

A definição e descrição dos casos de uso são os passos mais importantes na UML e no próximo capítulo o autor expica como foram escritos os casos de uso do exemplo do livro.

Próximo Capítulo

Capítulo 4 - Diagrama de Atividades e Descrição dos casos de uso

Documentos NOMENCLATURA e GLOSSÁRIO

Ainda no capítulo 2 o autor sugere a criação de um documento chamado NOMENCLATURA, que serve como padrão para todas as palavras envolvidas em estruturas de código, nos casos de uso ou ainda nas tabelas do banco de dados.
NOTA: Aqui na Meta, nós temos um padrão usado em todos os sistemas mas acho que deveríamos criar um documento contendo esses padrões, estando disponível facilmente através de uma intranet por exemplo..
Os novos colaboradores que se juntarem a equipe deverão se ADEQUAR aos formatos, e os formatos devem ser adotados de acordo com a empresa. A sugestão do autor é a seguinte:
Variáveis, Objetos e Classes
Escopo da Variável + Tipo da Variável + Nome da Variável
por exemplo:
iCodClinte -> variavel do tipo inteiro;
piCodCliente -> idem só que pública;
strNomeDoCliente -> Tipo String;
Nome de Operações
As operações ou métodos são prefixadas pelo tipo do seu retorno:
strObterNomeCliente -> O método retorna um tipoString;

NOTA: Bom, esses são os padrões que o autor do livro sugere, inclusive ele documenta TODAS AS VARIÁVEIS em uma lista, catalogando o prefixo que deverá ser usado. Acho que deveríamos ter um padrão desse tipo documentado, para cada uma das linguagens que trabalhamos, (VB6, VB.NET,....)

GLOSSÁRIO
Esse documento traduz para quem não conhece o software todos os termos usado pelo contrante. Tem função de agir como tradutor entre todos os participantes do processo de desenvolvimento do software.
NOTA: Na ferramente recem-adquirida (enterprise Architecth 4.0) existe suporte para o glossário, com uma separação para termos de negócio e termos técnicos.
Modelo de Glossário
Software: Locação de DVDs pela Internet
Locação - Ato de alugar um produto disponível no estoque da empresa.
Usuário Locador ou Cliente Locador - Aquele que aluga um produto.
... e assim vai ...


Próximos Capítulos
3. Caso de Uso
4. Diagrama de Atividades e Descrição dos Casos de Uso

Capítulo 2

A documentação de sistemas é sempre deixada de lado, ou por preguiça, ou por pressão do tempo . O autor sugere que para a documentação deixar de ser um problema, devemos nos preocupar com a documentação como uma das tarefas do desenvolvimento.

Eu queria fazer um a parte nesse momento. O que me deixou bastante entusiasmado com a UML é que gerando essa documentação nesse formato, a programação já estará no meio do caminho. Assim que criarmos Diagramas de classes e Diagramas de Sequência, o ato de programar se torna apenas o de traduzir o conteúdo dessa documentação em linguagem de programação.

Eu acredito que o maior trabalho estará em gerar essa documentação toda, mas assim que ela estiver definida uma equipe de programadores que saibam ler a UML poderão desempenhar sua atividade muito mais rapidamente e sem as dúvidas que passamos diariamente. Eu vejo um programador ler os casos de uso, analisar os diagramas e "mandar bala" e quando terminarem, os responsáveis pelos casos de uso verão que foi implementado o que estava "escrito". Tudo bem este é um cenário pouco comum, mas acho que temos muita capacidade para utilização desse processo....

Voltando ao livro ...
O Autor sugere três documentos iniciais:

Documento Visão

O documento visão é um relato resumido com os principais tópicos que o negócio deve fornecer. O autor usa este documento como parte do CONTRATO de desenvolvimento de software, mas eu acho que este é um documento sem muito segredo e quem tiver mais interesse pode consultá-lo na página 23 do livro.

Diagrama de Caso de Uso (Nível 0)

O Autor explica a notação, seguindo os itens na figura:

1. Ator - Sempre atua sobre um caso de uso, pode ser uma pessoa, um sistema, bem parecido com a ENTIDADE EXTERNA da análise estruturada.Dizemos que o ator "realiza uma atividade";

2. Caso de Uso - A Elipse representa o caso de uso que é uma ATIVIDADE ou uma macroação que o ator realiza;

3. Relação de dependência: A relação na figura indica que "Cadastrar beneficiário" depende diretamente da conclusão do caso de uso "Cadastrar Cliente";

4 e 5 - INCLUDE e EXTEND - Existem vários esteriótipos nos diversos diagramas em UML. Pra mim eles ainda são meio nebulosos, o autor explica que no caso do INCLUDE, o Caso de Uso Calcular Pontos utilizará integralmente a de Cálculo de Ponto de Fidalidade que se encontra documentada em Calcular Fidelidade.No caso do EXTEND, existe em cálculo em calcular bonificação e que esse cálculo irá se estender, ampliando o significado de uma fórmula já existente no Caso de Uso Calcular Fidelidade.

Conhecendo a notação, o autor sugere criar um Diagrama de Caso de Uso para a descrição que fez no documento visão, durante as explicações o autor utiliza a intenção de criar um software de locação de DVD pela internet, veja a descrição do documento visão e o diagrama criado em seguida:

"Este software tem o objetivo de disponibilizar a locação de DVDs, via Internet, a clientes já cadastrados ou ovos.

O software deve prever o cadastramento de usuários locadores, com seus dados pessoais, principalmente, os dados de endereço, que são tão importantes para a entrega como a recuperação de produtos alugados.
O software atenderá a todas as cidades onde o cliente contratante tiver depósito de DVD. Serão disponibilizados somente DVDs da cidade onde o cliente locador reside, visando à entrega.

O Cliente locador deve informar o modelo de seu equipamento de DVD, a fim de se avaliar se ele é ou não adequado a reproduzir o filme.

O cliente locador terá, no máximo, cinco dias para a devolução de um DVD alugado, sendo que esse período dependerá do tipo de DVD, que pode ser: desde Lançamentos até DVDs antigos. O processo de fidelizar o cliente locador leva em consideração tanto o número de locações quanto as decoluções pontuais.

A não devoluçào de um DVD no prazo estipulado implica pagamento de multa.

O Cliente locador pode designar, desde que apresente a documentação necessária, beneficiários capazes de efetivar um aluguel de DVD

As entregas serão feitas somente dentro da cidade em que o locador reside

Os administradores do site poderão, controlar Programa de Fidelidade, Programa de Promoções, Preços e Marketing

Os pagamentos serão feitos antecipadamente, pelo cartão de crédito ou boleto bancário."

Ainda nessa capítulo teremos o DOCUMENTO NOMENCLATURA.....
Capítulo 3 - Caso de USO

Capítulo 1 - Conhecimentos Iniciais

O Autor cita alguns conhecimentos importantes, entre eles o PROCESSO UNIFICADO e a UML.

PROCESSO UNIFICADO

Não acho que valha a pena se aprofundar agora nesse assunto, já que é um pouco massante e se refere ao PROCESSO de desenvolvimento de software completo prevendo as fase: Concepção, Elaboração, Construção e Transição. Para cada uma
dessas fazes temos um conjunto de atividades: Requisistos, Análise, Projeto, Implementação e Testes.
O autor sugere que a empresa adote um formato e exemplifica : XP(Extreme programming), RUP(Rational Unified Process), ICONIX, AM(Agile Modeling),etc.
Mas não existe um senso comum para criação de softwares, cada empresa adota o formato que deverá lhe proporcionar mais vantagens...
E a UML....?

UML

O Autor cita a UML como parte integrante do processo unificado de criação de software na empresa. Mas o que é UML?
A Finalidade da UML é proporcionar um padrão para a preparação de planos de arquitetura de projetos de sistemas, mas ela não indica como devemos fazer um software e sim indica as formas em que um software pode ser REPRESENTADO nos diversos estágios do seu desenvolvimento. Segundo Ivar Jacobson, 20% da UML resolve cerca de 80% dos problemas do dia-a-dia. A UML 2.0 é composta de 13 diagramas:
Atividades
Caso de Uso
Classe
Objetos
Sequencia
Comunicacao
Estado
Pacotes
Componentes
Implantação
Interaçào-Visão Geral
Timing
Composite Structure Diagram

Eu gostaria apenas de destacar que durante todo o livro o que é apresentado como mais importante é o CASO DE USO, muitos diagramas irão usar a descrição dos CASOS DE USO e no úlitmo capítulo do livro chamado de MÉTRICA DE CASO DE USO o autor sugere uma estivatima para medir o consumo de tempo para criação do software com base no CASO DE USO...

RESUMO FINAL

O Autor cita um resumo no final deste capítulo afim de sugerir um formato de utilização para o processo unificado e a UML, descrevendo maiores detalhes nos próximos capítulos:
Confecção do documento visão;
Criação de Diagrama de Caso de Uso
Formalização do documento Nomenclatura;
Formalização do documento Glossário;
Reunião inicial com todos os analistas e desenvolvedores;
Exploração de todos os Casos de Uso em diagramas;
Descrição dos Casos de Uso;
Aprovação dos Casos de Uso;
Início do Diagrama de Classes;
Início do Diagrama de Sequência;
Definição de Modelo de Entidade Relacionamento;
Conclusão da Interface Gráfica;
Aprovação do Protótipo com o Usuário;
Ínicio da codificação;
Construção dos demais diagramas necessários ao software.

PRÓXIMOS CAPÍTULO

2 - Documentos iniciais de um Software
3 - Caso de USO

Desenvolvendo Software com UML 2.0

Desenvolvendo Software com UML 2.0

O link refere-se ao livro que já comecei a ler e me inspirou a criar este blog para um estudo mais detalhado de como desenvolver software com uml. Estarei postando assuntos citados nos capítulos do livro e gostaria que todos compartilhassem desse estudo ...