Este documento fornece uma introdução sobre casos de uso no desenvolvimento de software, definindo o que são casos de uso e suas principais características. O autor explica que casos de uso mapeiam as interações entre atores e o sistema de forma a direcionar todo o desenvolvimento do software. Casos de uso devem ser especificados de forma a descrever o que o sistema fará e não como fará, além de fornecer resultados significativos para os atores no contexto do negócio.
O documento discute a importância de conhecer os processos de negócio de uma empresa para ser um bom gestor de TI. Ele explica o que são processos, dá exemplos de processos comuns em empresas e destaca que mapear e controlar processos é essencial para identificar oportunidades de melhoria e definir responsabilidades.
O documento discute a arquitetura orientada a serviços (SOA) e sistemas de gerenciamento de regras de negócio (BRMS). BRMS permite que usuários de negócios criem e modifiquem regras sem a necessidade de programação, reduzindo custos e melhorando a adaptação a regras dinâmicas. O documento também explica como as regras são representadas em BRMS e como fluxos de trabalho podem orquestrar sequências de regras.
A análise de requisitos é um processo importante na gestão de projetos para (1) recolher dados sobre as necessidades e expectativas dos usuários, (2) definir corretamente os requisitos do sistema, e (3) determinar o sucesso ou fracasso do projeto. Ela envolve técnicas como entrevistas e questionários para especificar funcionalidades, desempenho e restrições do sistema.
O documento discute a implantação do framework ITIL na empresa Mangels para gerenciamento de incidentes, com foco em fornecer soluções rápidas e minimizar impacto. Descreve o cenário anterior sem gestão de TI, a escolha do ITIL, e o novo processo de registro, triagem e resolução de incidentes usando ferramenta de gestão. Apresenta resultados com estatísticas de incidentes e desempenho dos analistas.
A maioria dos participantes (57%) soube do evento através de publicidade. Nenhum soube através de familiares. A maioria (6 pessoas) avaliou o evento como "muito bom" e apenas 1 pessoa o avaliou como "mau".
Ice boxes are available for purchase from Bayou Ice Boxes. They can be ordered online at bayouiceboxes.com or by calling 251.654.9736. The website and phone number provided are resources for learning more about and purchasing ice boxes.
O documento discute a importância de conhecer os processos de negócio de uma empresa para ser um bom gestor de TI. Ele explica o que são processos, dá exemplos de processos comuns em empresas e destaca que mapear e controlar processos é essencial para identificar oportunidades de melhoria e definir responsabilidades.
O documento discute a arquitetura orientada a serviços (SOA) e sistemas de gerenciamento de regras de negócio (BRMS). BRMS permite que usuários de negócios criem e modifiquem regras sem a necessidade de programação, reduzindo custos e melhorando a adaptação a regras dinâmicas. O documento também explica como as regras são representadas em BRMS e como fluxos de trabalho podem orquestrar sequências de regras.
A análise de requisitos é um processo importante na gestão de projetos para (1) recolher dados sobre as necessidades e expectativas dos usuários, (2) definir corretamente os requisitos do sistema, e (3) determinar o sucesso ou fracasso do projeto. Ela envolve técnicas como entrevistas e questionários para especificar funcionalidades, desempenho e restrições do sistema.
O documento discute a implantação do framework ITIL na empresa Mangels para gerenciamento de incidentes, com foco em fornecer soluções rápidas e minimizar impacto. Descreve o cenário anterior sem gestão de TI, a escolha do ITIL, e o novo processo de registro, triagem e resolução de incidentes usando ferramenta de gestão. Apresenta resultados com estatísticas de incidentes e desempenho dos analistas.
A maioria dos participantes (57%) soube do evento através de publicidade. Nenhum soube através de familiares. A maioria (6 pessoas) avaliou o evento como "muito bom" e apenas 1 pessoa o avaliou como "mau".
Ice boxes are available for purchase from Bayou Ice Boxes. They can be ordered online at bayouiceboxes.com or by calling 251.654.9736. The website and phone number provided are resources for learning more about and purchasing ice boxes.
O documento defende a fraternidade humana e a igualdade entre pessoas de diferentes povos, raças e classes. Ele sugere que, quando as pessoas se encontrarem, devem se tratar como amigos e que, unindo as mãos, podem transformar o mundo. Também propõe que, se cada um espalhar a semente da fraternidade, o sonho de uma grande fraternidade humana poderá se tornar realidade um dia.
O documento reflete sobre as dificuldades e desafios da vida, como desistir dos sonhos ou sentir solidão. No entanto, também fala sobre continuar insistindo em acreditar, transformar e dividir com os outros, com fé em que Deus irá mostrar o caminho, por mais difícil que seja. A mensagem final é a de insistir em seguir em frente e ser feliz.
Este documento apresenta uma aula sobre a dengue, seu mosquito transmissor Aedes aegypti, sintomas da doença e medidas para evitar sua proliferação. Os alunos farão pesquisas em grupos sobre a dengue e produzirão uma cartilha sobre os cuidados e prevenção da doença.
O documento lista as bandeiras de vários países africanos, descrevendo brevemente que uma bandeira representa um país ou organização e que a África é um continente composto por muitos países, cada um com sua própria bandeira única.
Maria Lúcia Souza Gomes compartilha sua história de vida. Aos 25 anos, ela ganhou na loteria e investiu o dinheiro em imóveis e uma fábrica de biscoitos para empregar sua família. Anos depois, descobriu que cinco irmãos desviaram dinheiro de suas empresas, deixando-a com uma grande dívida. Seus funcionários se ofereceram para trabalhar horas extras para quitar a dívida. Ela conseguiu pagar a dívida e manter suas empresas.
O documento apresenta uma lista de tarefas divididas em Main Quest e Side Quests relacionadas a análise de jogos populares no Facebook. A Main Quest inclui listar os 5 jogos mais populares, analisar 3 jogos até nível 5 focando em mecânicas, integração social, monetização e comunicação, e citar 2 melhores jogos do ano passado. As Side Quests incluem analisar empresas de jogos sociais, notícias de aquisições, comparar jogos distantes no ranking e traçar perfis de público-alvo.
Cada vez mais difundidos, os métodos ágeis como Scrum e XP tem demonstrado
sucesso ao serem aplicados no desenvolvimento de softwares de diversos
níveis de complexidade e tamanho. Porém, para obtermos resultados realmente
efetivos, é necessário entender que Agilidade requer disciplina e uma
profunda mudança cultural. Nesta palestra discutiremos alguns elementos
essenciais desta fascinante revolução na Engenharia de Software.
O documento descreve uma atividade lúdica sobre a Batalha Naval realizada em uma disciplina eletiva. Os alunos pesquisaram a história e as regras do jogo e escreveram um texto colaborativo sobre o assunto. A atividade teve como objetivo promover o aprendizado ativo e significativo por meio de um jogo educacional.
Este documento discute la importancia de la ética en los negocios. Explica que la ética trata de las obligaciones morales de los individuos y las normas que rigen las relaciones humanas. También describe cómo el ambiente cambiante de los negocios influye en los grupos de interés y los desafíos éticos que enfrentan las empresas. Finalmente, enfatiza que la ética profesional es necesaria para guiar las decisiones de manera responsable y prevenir problemas como la corrupción.
Es 04 desenvolvimento de software dirigido por casos de uso - parte iiiRodrigo Gomes da Silva
Este documento discute o uso de casos de uso de negócio para mapear processos de negócio do cliente de forma clara. Casos de uso de negócio descrevem a interação entre atores de negócio e processos de negócio para atingir objetivos de negócio. Eles são úteis para analistas entenderem e melhorarem processos de negócio e fornecer contexto para desenvolvedores.
Gestao da tecnologia_da_informacao_unidade_iimambrosino
O documento discute a importância do treinamento antes de usar novos softwares no trabalho, e como as empresas podem gerenciar riscos e custos durante mudanças tecnológicas e de negócios por meio do planejamento e engajamento dos funcionários. Ele também define termos como SLA, SLM, OLA e contratos de suporte.
O documento defende a fraternidade humana e a igualdade entre pessoas de diferentes povos, raças e classes. Ele sugere que, quando as pessoas se encontrarem, devem se tratar como amigos e que, unindo as mãos, podem transformar o mundo. Também propõe que, se cada um espalhar a semente da fraternidade, o sonho de uma grande fraternidade humana poderá se tornar realidade um dia.
O documento reflete sobre as dificuldades e desafios da vida, como desistir dos sonhos ou sentir solidão. No entanto, também fala sobre continuar insistindo em acreditar, transformar e dividir com os outros, com fé em que Deus irá mostrar o caminho, por mais difícil que seja. A mensagem final é a de insistir em seguir em frente e ser feliz.
Este documento apresenta uma aula sobre a dengue, seu mosquito transmissor Aedes aegypti, sintomas da doença e medidas para evitar sua proliferação. Os alunos farão pesquisas em grupos sobre a dengue e produzirão uma cartilha sobre os cuidados e prevenção da doença.
O documento lista as bandeiras de vários países africanos, descrevendo brevemente que uma bandeira representa um país ou organização e que a África é um continente composto por muitos países, cada um com sua própria bandeira única.
Maria Lúcia Souza Gomes compartilha sua história de vida. Aos 25 anos, ela ganhou na loteria e investiu o dinheiro em imóveis e uma fábrica de biscoitos para empregar sua família. Anos depois, descobriu que cinco irmãos desviaram dinheiro de suas empresas, deixando-a com uma grande dívida. Seus funcionários se ofereceram para trabalhar horas extras para quitar a dívida. Ela conseguiu pagar a dívida e manter suas empresas.
O documento apresenta uma lista de tarefas divididas em Main Quest e Side Quests relacionadas a análise de jogos populares no Facebook. A Main Quest inclui listar os 5 jogos mais populares, analisar 3 jogos até nível 5 focando em mecânicas, integração social, monetização e comunicação, e citar 2 melhores jogos do ano passado. As Side Quests incluem analisar empresas de jogos sociais, notícias de aquisições, comparar jogos distantes no ranking e traçar perfis de público-alvo.
Cada vez mais difundidos, os métodos ágeis como Scrum e XP tem demonstrado
sucesso ao serem aplicados no desenvolvimento de softwares de diversos
níveis de complexidade e tamanho. Porém, para obtermos resultados realmente
efetivos, é necessário entender que Agilidade requer disciplina e uma
profunda mudança cultural. Nesta palestra discutiremos alguns elementos
essenciais desta fascinante revolução na Engenharia de Software.
O documento descreve uma atividade lúdica sobre a Batalha Naval realizada em uma disciplina eletiva. Os alunos pesquisaram a história e as regras do jogo e escreveram um texto colaborativo sobre o assunto. A atividade teve como objetivo promover o aprendizado ativo e significativo por meio de um jogo educacional.
Este documento discute la importancia de la ética en los negocios. Explica que la ética trata de las obligaciones morales de los individuos y las normas que rigen las relaciones humanas. También describe cómo el ambiente cambiante de los negocios influye en los grupos de interés y los desafíos éticos que enfrentan las empresas. Finalmente, enfatiza que la ética profesional es necesaria para guiar las decisiones de manera responsable y prevenir problemas como la corrupción.
Es 04 desenvolvimento de software dirigido por casos de uso - parte iiiRodrigo Gomes da Silva
Este documento discute o uso de casos de uso de negócio para mapear processos de negócio do cliente de forma clara. Casos de uso de negócio descrevem a interação entre atores de negócio e processos de negócio para atingir objetivos de negócio. Eles são úteis para analistas entenderem e melhorarem processos de negócio e fornecer contexto para desenvolvedores.
Gestao da tecnologia_da_informacao_unidade_iimambrosino
O documento discute a importância do treinamento antes de usar novos softwares no trabalho, e como as empresas podem gerenciar riscos e custos durante mudanças tecnológicas e de negócios por meio do planejamento e engajamento dos funcionários. Ele também define termos como SLA, SLM, OLA e contratos de suporte.
20130301 white paper modelagem de processos de negócio (bpm)_soft_expertSamuel Gonsales
O documento discute várias técnicas de modelagem de processos de negócio, incluindo diagramas de fluxo de trabalho, decomposição, casos de uso, entidade-relacionamento e eventos. A modelagem de processos pode melhorar a compreensão dos processos de negócio e identificar oportunidades de melhoria. Profissionais habilidosos em várias técnicas de modelagem são mais valiosos do que a adoção rígida de um único padrão.
O documento discute a abordagem BPM 2.0 para modelagem e execução de processos de negócio. Apresenta BPM 2.0 como uma alternativa à primeira versão de BPM que não atendeu às necessidades dos clientes. Defende que BPM 2.0 deve ser usado por analistas de processos técnicos, não por analistas de negócios. Recomenda iniciar com um Sistema de Gerenciamento de Processos de Negócio (BPMS) completo em vez de apenas uma ferramenta de modelagem, para permitir a criação de processos executáveis desde
O documento discute os benefícios de uma abordagem de BPM 2.0, que envolve iniciar com um Sistema de Gerenciamento de Processos de Negócio (BPMS) completo em uma única ferramenta no Eclipse, ao invés de múltiplas ferramentas de múltiplos fornecedores. O BPMS completo permite modelar, executar e monitorar processos de forma integrada, enquanto o Eclipse facilita a integração e reutilização de componentes de terceiros. A abordagem proposta visa simplificar o BPM e torn
O documento discute casos de uso, apresentando sua introdução, elementos, construção, documentação e uso em processos iterativos. Aborda diagramas de casos de uso, identificação de atores e casos, descrição textual e validação do modelo.
1. A engenharia de requisitos envolve a descoberta do que o sistema deve fazer e possíveis restrições através de técnicas como entrevistas, observação e prototipagem.
2. É importante documentar os requisitos levantados para que sirvam de base para o desenvolvimento de software.
3. As principais etapas da engenharia de requisitos são concepção, levantamento, elaboração, negociação, especificação, validação e gestão.
Aborda aspectos da elicitação, gestão e documentação dos requisitos de um software. Estudo dos desafios que o analista de sistemas precisa enfrentar. Expõe exemplos dos tipos de artefatos de requisitos que podem ser documentados. Recomenda melhores práticas para a escrita dos requisitos e casos de uso.
O documento apresenta os principais tópicos sobre programação visual e console, modelos de desenvolvimento de software como RAD e cascata, e o que é uma IDE. O RAD é definido como um modelo incremental que enfatiza um curto ciclo de desenvolvimento de até 90 dias, dividido em 5 etapas. Uma IDE é descrita como um programa para desenvolver outros programas, com exemplos como Delphi, Visual Studio e NetBeans.
TDC2018FLN | Trilha UX - Os desafios para viabilizar a experiência do usuário...tdc-globalcode
O documento discute os desafios da experiência do usuário em aplicações de big data. Ele apresenta o caso de uma empresa que monitora autorizações médicas e coleta grandes volumes de dados de diferentes fontes para tomar decisões rápidas. O sistema possui regras padrão, mas permite customização através de grupos e fluxos para mapear a jornada dos itens monitorados.
1) O documento descreve a aplicação de técnicas de modelagem de processos de negócio para apoiar a especificação de requisitos de um sistema para uma instituição pública brasileira. 2) A modelagem dos processos de negócio foi realizada utilizando a notação UML e resultou na identificação de problemas e possibilidades de melhoria nos processos mapeados. 3) Os resultados da modelagem dos processos serviram de insumo para a especificação de requisitos do sistema de software.
O documento descreve um estudo de aplicação de modelagem de processos de negócio para apoiar a especificação de requisitos de um sistema. O estudo envolveu modelar os processos de uma instituição pública de Minas Gerais usando a notação UML para melhor compreender suas necessidades e problemas, e assim identificar requisitos para um novo sistema de software.
Este trabalho tem como principal objetivo trazer definições das soluções de softwares BI, ERP, CRM, BPM e também fazer a definição de Web Semântica, demonstrando a importância de cada um deles, e expondo também o quão favoráveis podem ser a aquisição dessas ferramentas, facilitando o dia-a-dia de seus usuários, trazendo praticidade e agilidade, reduzindo em um número bem considerável o tempo gasto para realização de determinadas tarefas. Esperamos com este trabalho acabar com as duvidas existentes e expor de uma maneira bem simples os temas abordados.
O documento discute a Web3 e a nova internet descentralizada, explicando como o blockchain permite dar poder aos usuários sobre seus dados. Apresenta também modelos de negócios como SaaS, success fee e o modelo Canvas para análise de startups.
1) O documento discute sistemas de informação, incluindo sistemas de processamento de transações (SPT) e sistemas de informações gerenciais (SIG). SPTs automatizam tarefas diárias como controle de estoque, enquanto SIGs fornecem informações para tomada de decisões gerenciais.
2) SIGs se diferenciam de SPTs ao fornecer relatórios analíticos e resumidos para gerentes, em vez de dados detalhados. SIGs apoiam decisões semi-estruturadas de nível gerencial.
O documento discute como a combinação de Business Process Management (BPM) e Business Intelligence (BI) pode melhorar o gerenciamento de Service Level Agreements (SLAs). BPM fornece monitoramento em tempo real de processos para garantir o cumprimento dos SLAs, enquanto BI permite análises históricas para melhorias estratégicas. Juntos, BPM e BI oferecem visibilidade dos processos de ponta a ponta e informações precisas para tomada de decisões preventivas e planejamento.
Modelagem dos Processos de Negócio para a Definição de Requisitos de SistemasImpacta Eventos
1. O documento discute a importância da modelagem dos processos de negócio antes da definição de requisitos de sistemas de software. 2. Apesar da evidência de que entender os processos de negócio é essencial, a maioria das empresas de desenvolvimento de software negligencia esta etapa. 3. O palestrante irá apresentar sua opinião sobre o estado atual desta área e expectativas futuras.
Este documento fornece uma introdução aos conceitos básicos de gestão de processos de negócios. Aborda definições de processo, a diferença entre processos e projetos, e as visões funcional e por processo de uma organização. Também discute a importância da modelagem e mapeamento de processos para melhorar a estratégia e desempenho de uma empresa.
O documento discute como realizar testes de interface do usuário, abordando 4 aspectos principais: 1) verificar se as informações estão corretas, 2) testar se as mudanças na tela ocorrem como esperado após ações do usuário, 3) testar a acessibilidade, e 4) verificar a usabilidade. Também discute a importância da automação dos testes de interface.
O documento descreve o software e-MON desenvolvido pela Dimension Data para automatizar processos de TI e melhorar a qualidade e controle dos serviços oferecidos. O e-MON centraliza informações da infraestrutura de TI, permite monitoramento em tempo real e automação de processos para reduzir tempos de resolução e custos e aumentar a qualidade dos serviços. O software integra diversas ferramentas de gerenciamento e permite definir processos de acordo com melhores práticas para gestão da infraestrutura de TI.
Semelhante a Es 02 desenvolvimento de software dirigido por casos de uso - parte i (20)
O documento fornece uma visão geral do BABOK, o guia de conhecimento para análise de negócios do IIBA. Ele descreve as seis áreas de conhecimento do BABOK, incluindo planejamento, elicitação, gerenciamento de requisitos, análise corporativa, análise de requisitos e avaliação de soluções. O documento argumenta que os analistas de negócios podem ter melhores resultados seguindo as práticas recomendadas no BABOK.
O documento descreve a biografia e experiência profissional de Marcelo Neves, um especialista em análise de negócios no Brasil. Ele é formado em computação, presidente do Capítulo Rio de Janeiro do IIBA e ministra palestras sobre o assunto. Neves também é coautor de livros sobre gestão de analistas de negócios e preparação para certificações.
Este documento apresenta os conceitos básicos de gerenciamento de requisitos de software, incluindo definições de requisitos e gerenciamento de requisitos. Ele discute a aplicação dessas técnicas em diferentes tipos de aplicações de software e sistemas, e introduz o mapeamento do domínio do problema para o domínio da solução através da identificação de stakeholders, características e requisitos do sistema.
O documento apresenta um curso sobre orientação a objetos com PHP, abordando conceitos como classes, atributos, métodos, construtores, herança e polimorfismo. O curso também mostra como acessar bancos de dados MySQL usando classes.
Este documento apresenta o professor Rodrigo Gomes da Silva e seu seminário sobre o Processo Iterativo com RUP. Ele fornece seus contatos, certificações, formação acadêmica e experiência profissional, além da agenda do seminário, que inclui tópicos como sintomas de problemas em desenvolvimento de software, as melhores práticas da engenharia de software, princípios do desenvolvimento iterativo, o processo RUP e suas fases, disciplinas, papéis e artefatos.
Este documento apresenta um treinamento sobre introdução à UML com casos de uso. O treinamento é ministrado por Rodrigo Gomes, que é analista de requisitos na IBM e professor universitário. O treinamento aborda conceitos básicos de UML, casos de uso, diagramas de casos de uso e levantamento de requisitos com casos de uso.
O documento apresenta informações sobre a disciplina de Computação no curso de Tecnólogo em Análise e Desenvolvimento de Sistemas da UNIS. A disciplina abordará tópicos como história da computação, arquitetura de computadores, algoritmos, banco de dados e linguagens de programação. Será avaliada por meio de provas, trabalhos e um PIC ao longo de 80 horas com aulas teóricas e práticas ministradas pelo professor Rodrigo Gomes.
A disciplina de Computação terá 80 horas de carga horária distribuídas em 4 aulas semanais. Os conteúdos incluem o histórico e funcionamento dos computadores, sistemas de numeração, arquitetura de hardware e software, áreas da computação e utilização de computadores. As avaliações serão feitas por provas, trabalhos individuais e em grupo e seminários.
O documento discute o comércio eletrônico, definindo-o como uma nova forma de conduzir negócios através da Internet e analisando suas oportunidades e desafios em comparação ao comércio tradicional, como a segurança das transações online e a necessidade de oferecer informações detalhadas sobre os produtos.
O documento discute a importância da auditoria de sistemas de informação para garantir a segurança e integridade da informação nas empresas. Ele explica como a informação é um ativo valioso que requer proteção e como as políticas de segurança, treinamento de funcionários e auditoria dos sistemas podem ajudar a mitigar riscos.
O documento discute a pirataria de software, definindo-a como a cópia, distribuição ou venda ilegal de programas de computador. A pirataria é considerada crime pela lei brasileira e pode acarretar em multas e prisão. O documento também apresenta as vantagens do uso de software livre como alternativa à pirataria.
Este documento discute conceitos importantes de segurança da informação, incluindo SPAM, vírus, worms e certificação digital. A certificação digital é apresentada como uma tecnologia que permite autenticação, confidencialidade e integridade em transações eletrônicas através do uso de criptografia de chave pública.
O documento discute conceitos de segurança da informação como confidencialidade, integridade e disponibilidade. Também aborda técnicas de engenharia social que podem ser usadas para roubar informações, como persuasão e ataques online. É importante que empresas treinem funcionários e implementem políticas de segurança para prevenir esses riscos.
O documento discute engenharia social, que caracteriza-se por explorar a fragilidade das pessoas para obter informações ou acesso indevido. Apresenta tipos de ataques como físico no local de trabalho ou psicológico usando persuasão. Também descreve formas de prevenção como políticas de segurança e treinamento de funcionários.
Asi na 01_conquistando_vantagem_competitiva_com_os_sistemas_de_informacaoRodrigo Gomes da Silva
Este documento discute como as empresas podem conquistar vantagens competitivas por meio dos sistemas de informação. Apresenta o modelo das cinco forças competitivas de Porter e como a TI pode ser alinhada aos objetivos de negócios para apoiar estratégias de liderança em custos, diferenciação de produtos e foco em nichos de mercado. Também discute o impacto da Internet e da nuvem na competitividade das empresas.
Asi na 01_conquistando_vantagem_competitiva_com_os_sistemas_de_informacao
Es 02 desenvolvimento de software dirigido por casos de uso - parte i
1. Desenvolvimento de Software
Dirigido por Caso de Uso
Parte I: Conceituando e Entendendo Caso de Uso
C
Vinicius Lourenço de Sousa
viniciuslsousa@hotmail.com
Atua no ramo de desenvolvimento de software
há mais de 10 anos, é autor de diversos artigos
publicados pelas revistas ClubeDelphi e SQL
Magazine. É Graduado em Tecnologia da Informação pela ABEU Faculdades Integradas e
Pós-Graduado em Análise, Projeto e Gerência
de Sistemas pela PUC-RJ, IBM Certified: Especialista Rational Unified Process e instrutor de
UML, Análise OO e Java. Atualmente trabalha
na CPM Braxis como Analista de Sistemas nas
áreas de arquitetura, especificação de requisitos, levantamento e modelagem de processo
de negócio e projetista de software em soluções com componentes de negócio e SOA.
36
ada vez mais o desenvolvimento
de software fica mais complexo.
Devemos isso às regras de negócios das grandes corporações que por sua
vez estão cada vez mais complexas. O
mundo não é mais o mesmo, ele tornouse pequeno graças à internet. Milhares
de pessoas têm acesso às informações e
aos produtos vendidos no mercado praticamente de forma instantânea. Isso fez
com que as empresas também tivessem
que investir para ganhar espaço nesse
“Mundo Novo”.
Então, para que o desenvolvimento de
software tenha sucesso, é fundamental
que nós desenvolvedores de software tenhamos a total compreensão do processo
de negócio dos clientes. Com isso pode-se
entender claramente a real necessidade
dos clientes em relação ao seu próprio
negócio. Com o conhecimento sobre o
negócio, temos a noção dos riscos para o
desenvolvimento e como o software deverá se comportar no dia a dia do cliente.
Mas sabemos que em desenvolvimen-
to de software nada é constante e sim
mutável. As regras mudam a toda hora,
manutenções são feitas em funcionalidades já entregues, novos sistemas
surgem e se comunicam com o nosso
através de vários protocolos e tecnologias
diferentes. Entretanto, o pior de tudo é
quando uma determinada informação
do negócio muda ou uma nova funcionalidade passa a existir, pois isso acaba
acarretando várias alterações em cascata
no desenvolvimento do software, como:
fazer novamente a análise, o projeto, a implementação, os testes e etc. Dessa forma,
é necessário ter uma maneira de mapear
e manter registrado todos os requisitos e
regras de negócio do cliente para que no
futuro possamos ter uma rastreabilidade
de impacto no caso de alteração de um
requisito ou de uma regra de negócio.
Essa rastreabilidade é de total importância, pois com ela pode-se determinar, por
exemplo, a complexidade da alteração, os
artefatos (documentos) que necessitarão
serem alterados e o prazo da alteração do
Engenharia de Software Magazine – Desenvolvimento de Software Dirigido por Caso de Uso
2. REQU I SITO S
software, pois como diz o ditado, “tempo
é dinheiro”.
Atualmente, existe um artefato muito
utilizado que nos permite dirigir todo
o desenvolvimento de software. Com
ele, podem-se rastrear os impactos nos
requisitos de software e nos demais artefatos que foram criados a partir dele.
Esse artefato chama-se Caso de Uso (Use
Case). O caso de uso é usado em todo
desenvolvimento através de vários “cenários” e por vários membros da equipe
de desenvolvimento. Por exemplo: na
criação da arquitetura do software, na
análise e projeto físico, na criação dos
planos de testes e etc.
A motivação em escrever este artigo
está no fato de ter percebido que muitas
pessoas não sabem o que é um caso de
uso realmente, ou seja, criam um caso
de uso de maneira errada que ao invés de
ajudar no desenvolvimento do software,
acabará trazendo problemas no futuro.
Para que isso não ocorra, temos que primeiro entender o que é um caso de uso
antes de sair especificando-o.
Entendendo o que é um Caso de Uso
Muitos analistas de sistemas criam
casos de usos e seus diagramas de forma
inapropriada. Com isso, todo o desenvolvimento de software é afetado, gerando
inúmeras dificuldades no entendimento
da aplicação. Na verdade, para um caso
de uso ser considerado válido, sua especificação deve seguir algumas regras. Essas
regras existem exatamente para deixar
os casos de usos com fácil entendimento
não só pela equipe de desenvolvimento,
mas também pelos clientes. Vejam quais
são essas regras:
Um caso de uso é uma seqüência de
interações entre o ator (alguém ou algo
que interage com o sistema) e o sistema,
que acontece de forma atômica, na perspectiva do ator.
Isso significa que quando criamos um
caso de uso apenas nos preocupamos
com “o que” o sistema deve fazer e não
com “o como” deve fazer. E aí está o maior
erro existente em vários casos de uso
que eu tenho encontrado em meus anos
como desenvolvedor de software. Vários
analistas quando especificam os casos de
uso, acabam colocando como deve ser
feito um determinado passo ou fluxo,
descrevendo que aquela informação deve
ser salva naquela tabela e/ou que aquela
informação deve ser lida daquela tabela
e daquele campo.
Nunca devemos esquecer que a especificação do caso de uso será lida e validada
pelo nosso cliente e que eles podem ser ou
não da área de TI. Neste caso, mesmo se
forem, o objetivo principal do caso de uso
é mapear o que o sistema deve fazer. Essa é
a principal validação que o cliente fará no
caso de uso e não se as informações ficarão
na tabela XYZ e no campo ABC. Mas então, em que momento no desenvolvimento
de software deve-se começar a pensar em
como o sistema executará as funcionalidades? Isso fica para o projeto físico, onde aí
sim nos preocuparemos com toda a parte
tecnológica do sistema como banco de
dados, servidores de aplicação, linguagem
de desenvolvimento, estratégias de transação, alocação de memória e etc.
O fato das interações entre o ator e o
sistema serem atômicas na perspectiva do
ator, significa que cada passo representa
uma única operação tanto por parte do
ator quanto do sistema. Também significa que essa operação ao final de sua
execução retornará o resultado esperado
em caso de sucesso, não podendo haver
resultados parciais.
Ao ser executado, um caso de uso deve
fornecer um resultado observável e
significativo para o ator.
Todo caso de uso deve representar
uma solução sistêmica para o negócio do
cliente, ou seja, não devem existir casos
de uso para soluções tecnológicas como
explicado no item anterior. E isso tem
bastante influência no resultado que um
caso de uso deve retornar para o ator,
pois esse resultado também deve estar
inserido dentro do contexto do negócio
do cliente.
Como exemplo, posso citar um caso de
uso para saque de dinheiro em um caixa
eletrônico. Quando vamos ao caixa eletrônico para sacar dinheiro nós iniciamos um
processo de negócio que conterá vários passos. Ao final do processo o resultado será o
dinheiro que a máquina liberará, contando
que tudo deu certo durante o processo.
Perceba que o ato de sacar dinheiro pelo
cliente é uma operação que está dentro
do processo de movimentação bancária
de qualquer banco existente, assim como
as demais operações como transferência,
depósito e etc. Portanto, percebemos que
o resultado do caso de uso realmente está
dentro do contexto do processo de negócio,
pois o que se deseja é o dinheiro que é
objeto da movimentação.
Um caso de uso representa uma visão
externa do sistema. Ficam registradas
todas as informações trocadas entre o
ator e o sistema. Com isso obtemos o que
chamamos de “contorno do sistema” ou
“fronteira do sistema”.
Como expliquei no primeiro item, em
um caso de uso não se deve colocar como
o sistema deve fazer o processo e sim o
que ele tem que fazer. Dessa forma podemos determinar as responsabilidades dos
atores e do sistema na execução de suas
tarefas, pois como veremos mais a frente,
atores também podem ser outros sistemas. Então imagine se o nosso sistema
tivesse que interagir com outro sistema
que já está pronto. Nós apenas queremos
saber que tipo de funcionalidade (serviço) esse sistema pode nos oferecer e não
como ele executa essa funcionalidade
internamente. Vejamos a Figura 1 para
entendermos melhor.
Na Figura 1, vemos um diagrama de
caso de uso para venda de ingressos pela
internet. Nele o cliente envia as informações do seu cartão de crédito para a compra do ingresso. O nosso sistema deverá
enviar essas informações para o sistema
da operadora do cartão de crédito afim
de validação. Repare que o diagrama tem
dois atores, um (Cliente) sendo um usuário
do nosso sistema e o outro (Operadora de
Cartão de Crédito) sendo o sistema ex-
Figura 1. Venda de ingresso pela Internet
Edição 02 – Engenharia de Software Magazine
37
3. de saque e depósito. Sabemos que nessas
movimentações, existem passos que sempre serão executadas e um desses passos
é a identificação do cliente, onde o cliente
coloca seu cartão e o sistema validará os
dados como agência, número da conta e
senha para saber se é um cliente válido
que pode fazer a movimentação. Por ser
um passo de muita importância no contexto do negócio do cliente e por mais de
um caso de uso ter esses mesmos passos,
nós podemos separá-los a fim de reutilizarmos essa parte da interação ator e
sistema. Mas devemos ter muito cuidado
ao fazer isso, pois podemos acabar tendo uma enxurrada de casos de uso sem
necessidade. A ponderação do que é importante para o negócio e para o sistema
deve predominar nesse momento.
Agora que entendemos o que é um caso
de uso, mostrarei algumas características
importantes de um diagrama de caso
de uso.
Figura 2. Movimentação Bancária
Características importantes de um
diagrama de caso de uso
Figura 3. Movimentação Bancária
terno que validará os dados do cartão de
crédito do cliente. Note que, assim vamos
obtendo a “fronteira do sistema” que é
tudo que o ator enxerga e/ou percebe do
sistema, ou seja, as informações passadas
para o sistema pelo ator e as informações
passadas para o ator pelo sistema. Quando a informação dada pelo ator atravessa
a fronteira do sistema, ela está dentro
do sistema e o ator não sabe como essa
informação será tratada, só importando
o resultado.
Casos de uso com poucos passos
devem ser avaliados se são realmente
significativos para serem casos de uso e
não parte de um caso de uso maior.
Esse item deve ser levado com muita
atenção, pois às vezes é muito difícil decidir se um caso de uso é na verdade passos
de outro caso de uso maior ou se um caso
de uso é na realidade vários casos de uso
embutidos que devem ser separados. Para
38
tomarmos essa decisão devemos levar em
conta alguns aspectos:
• Ter total conhecimento do processo de
negócio do cliente;
• Sabermos se os passos de um caso
de uso serão usados por outros casos de
uso e assim podermos fazer reuso desses
passos como outro caso de uso.
Ao criarmos um diagrama de caso de
uso, também devemos nos atentar para
certas características para que o diagrama
não fique errado ou confuso no momento
da especificação:
• Ator: Alguém ou algo que interage
com o sistema. Um ator pode ser uma
pessoa, um sistema externo (por exemplo:
Figura 1) ou um hardware.
Para atores que representam pessoas,
não podemos nomeá-los com os nomes
das pessoas e sim com os papéis que
essas pessoas representam dentro do
contexto do negócio. Por exemplo: na
Figura 2, temos o ator Cliente que pode
efetuar um saque ou um depósito. O
Lembre-se que um caso de uso é uma
seqüência de interações entre o ator e
o sistema e, por isso, casos de uso com
poucos passos tendem a não mostrar
essa interação de forma que possamos
entender o processo de negócio. Por outro lado, existem passos tão importantes
no contexto do negócio do cliente que
muitas vezes é interessante separá-los
para podermos fazer reuso desses passos.
Vejamos a Figura 2 para entendermos
melhor.
Na Figura 2, vemos um diagrama de
caso de uso para movimentação bancária
Engenharia de Software Magazine – Desenvolvimento de Software Dirigido por Caso de Uso
5. casos de uso Sacar Dinheiro e Depositar
Dinheiro incluem o caso de uso Identificar
Usuário e o caso de uso Abrir Conta inclui
Definir Cliente. Isso significa que os casos
de uso Identificar Usuário e Definir Cliente
sempre serão chamados quando Sacar
Dinheiro, Depositar Dinheiro e Abrir Conta
forem executados.
Extend: Essa característica significa
que o caso de uso poderá ou não ser executado, ou seja, dependerá do resultado
de uma condição de negócio para ser
decidido se ele será executado. Casos de
uso que estendem são executados nos
cenários alternativos (cenários alternativos serão detalhados mais para frente).
Como exemplo, veja na Figura 6 que o
Auxiliar Administrativo ao inscrever
um aluno em um treinamento poderá
ou não atualizar os dados cadastrais do
aluno. Se for a primeira vez que o aluno
é inscrito no treinamento, então ele será
cadastrado. Se for o segundo treinamento
em diante o aluno poderá ter ou não seus
dados cadastrais atualizados.
Figura 6. Exemplo de Extend
40
tem o mesmo objetivo que uma herança
de classes em um diagrama de classe, ou
seja, quando queremos atribuir novas características ao caso de uso sem perder a
sua essência, criamos casos de uso (filho)
que herdam do caso de uso mais abstrato
(pai). Para entendermos melhor vejamos
a Figura 5. Observe que na Figura 5
existe um caso de uso abstrato chamado
Consultar Saldo que serve para fazer as
consultas do saldo da conta. No entanto,
essa consulta pode ser feita na tela de um
terminal ou ser impressa e dependendo
da opção escolhida, a formatação das
informações da consulta será diferente e
até mesmo algumas informações poderão
ser ou não apresentadas. Para resolver
esse caso, foi feita a herança do caso de
uso, criando os casos de uso Consultar
Saldo Impresso e Consultar Saldo na Tela. O
caso de uso Consultar Saldo terá todos os
passos e regras comuns que serão usados
pelos casos de uso filhos. Repare que a
essência deles permanece inalterada, ou
seja, consultar saldo. Apenas foram atribuídas funcionalidades diferentes para
cada situação.
• Reuso de Caso de Uso: Como demonstrado na Figura 4, podemos reutilizar casos de uso para aproveitarmos as mesmas
interações entre ator e sistema. Em um
diagrama, podemos reutilizar um caso
de uso de duas formas possíveis:
Conclusão
Nesta primeira parte vimos alguns erros na criação e especificação de casos de
uso e como evitá-los. Também vimos seus
conceitos, características e a importância
do caso de uso no desenvolvimento de
software. Na segunda parte do artigo explicarei detalhadamente como especificar
casos de uso.
Links
OMG: The Object Management Group
www.omg.org
RUP: Rational Unified Process 7.0
http://www-306.ibm.com/software/awdtools/rup/
Bibliografia
UML Essencial – 3ª Edição – Martin Fowler
Utilizando UML e Padrões - Larman, Craig
Include: Essa característica significa
que o caso de uso sempre será chamado.
Como exemplo, na Figura 4, onde os
!
Na Figura 3, foi criado um ator abstrato
chamado Usuário que é herdado pelos
atores Cliente, Caixa e Gerente. O ator
Usuário é quem irá executar os casos de
uso Sacar Dinheiro e Depositar Dinheiro,
sendo que dependendo do contexto na
realidade será ou o cliente ou o caixa
ou o gerente. Repare que o caso de uso
Identificar Cliente foi renomeado para
Identificar Usuário, pois agora pode ser
qualquer um dos três a fazer a movimentação.
Outro ganho que temos ao usar a herança de atores é que começamos a mapear
as permissões de acesso ao sistema. Por
exemplo, na Figura 4 somente o ator Gerente é que pode abrir uma conta na agência, ou seja, os outros atores não terão essa
permissão. O ator Cliente participa como
ator secundário, pois ele deverá informar
a senha da nova conta.
• Caso de Uso: Como já explicado, um
caso de uso mapeia a interação entre o
ator e o sistema. Nesta seção apenas incrementarei as características de caso de
uso dentro do diagrama de caso de uso.
Para uma perfeita compreensão do que
um caso de uso controla, é fundamental
que seu nome esteja dentro do contexto
do negócio. Portanto, bons nomes de
casos de uso são aqueles que o próprio
cliente utiliza no seu dia a dia, por exemplo, Abrir Conta, Sacar Dinheiro e etc.
• Herança de Casos de Uso: Assim
como podemos criar herança entre os
atores, também podemos criar herança
entre os casos de uso. Essa característica
Engenharia de Software Magazine – Desenvolvimento de Software Dirigido por Caso de Uso