Modelagem de Processos Autor: Prof. Dr. Ivanir Costa Colaboradores: Prof. Roberto Macias Profa. Elisângela Mônaco de Moraes Prof. Emanuel Augusto Severino de Matos
Professor conteudista: Dr. Ivanir Costa Doutor em Engenharia de Produção pela Escola Politécnica da Universidade de São Paulo (USP, 2003) e mestre em Engenharia de Produção pela Universidade Paulista (UNIP), pós-graduado em Sistemas de Informação pela UNIP, graduado em Física pela USP. Professor titular do programa de mestrado e doutorado da UNIP em Engenharia de Produção, onde realiza orientação para alunos doutorandos, mestrandos e da iniciação científica na graduação. Professor da EAD na UNIP, nas disciplinas de Qualidade de Software e Sistemas de Informação. Orientador de alunos de mestrado do IPT (Instituto de Pesquisas Tecnológicas) da USP, professor do curso Gestão da Tecnologia da Informação, MBA da FIA/FEA. Possui dezenas de publicações na área de Engenharia de Produção e Tecnologia da Informação no Brasil e no exterior. É consultor há mais de 30 anos em Tecnologia da Informação, com ênfase em Engenharia de Software e Qualidade de Software, atuando principalmente nos seguintes temas: desenvolvimento de software, metodologia de desenvolvimento, métricas de software, métodos ágeis, produção de software, qualidade de software e governança de TI.
Dados Internacionais de Catalogação na Publicação (CIP) C837m
Costa, Ivanir Modelagem de processos / Ivanir Costa. – São Paulo: Editora Sol, 2012. 144 p., il. Notas: este volume está publicado nos Cadernos de Estudos e Pesquisas da UNIP, Série Didática, ano XVII, n. 2-066/12, ISSN 1517-9230. 1. Tecnologia da informação. 2. Modelagem de processos. 3. Modelagem comportamental. I. Título. CDU 65.011.56
© Todos os direitos reservados. Nenhuma parte desta obra pode ser reproduzida ou transmitida por qualquer forma e/ou quaisquer meios (eletrônico, incluindo fotocópia e gravação) ou arquivada em qualquer sistema ou banco de dados sem permissão escrita da Universidade Paulista.
Prof. Dr. João Carlos Di Genio Reitor
Prof. Fábio Romeu de Carvalho Vice-Reitor de Planejamento, Administração e Finanças
Profa. Melânia Dalla Torre Vice-Reitora de Unidades Universitárias
Prof. Dr. Yugo Okida Vice-Reitor de Pós-Graduação e Pesquisa
Profa. Dra. Marília Ancona-Lopez Vice-Reitora de Graduação
Unip Interativa – EaD Profa. Elisabete Brihy Prof. Marcelo Souza Prof. Dr. Luiz Felipe Scabar Prof. Ivan Daliberto Frugoli
Material Didático – EaD
Comissão editorial: Dra. Angélica L. Carlini (UNIP) Dra. Divane Alves da Silva (UNIP) Dr. Ivan Dias da Motta (CESUMAR) Dra. Kátia Mosorov Alonso (UFMT) Dra. Valéria de Carvalho (UNIP) Apoio: Profa. Cláudia Regina Baptista – EaD Profa. Betisa Malaman – Comissão de Qualificação e Avaliação de Cursos Projeto gráfico: Prof. Alexandre Ponzetto Revisão: Virgínia Bilatto Amanda Casale
Sumário Modelagem de Processos APRESENTAÇÃO.......................................................................................................................................................7 INTRODUÇÃO............................................................................................................................................................7 Unidade I
1 A Linguagem Unificada de Modelos...............................................................................................11 1.1 Introdução.................................................................................................................................................11 1.2 Motivação para o uso de modelos................................................................................................. 12 1.3 Princípios da modelagem de software......................................................................................... 14 1.4 Modelagem e orientação a objetos............................................................................................... 15 1.5 Por que usar a orientação a objetos?............................................................................................ 16 1.6 Conceitos básicos da orientação a objetos................................................................................. 22 2 a linguagem unificada de modelos (uml)................................................................................. 28 2.1Introdução................................................................................................................................................. 28 2.2 A UML e o Processo Unificado......................................................................................................... 32 2.2.1 Engenharia de software e processos de software...................................................................... 33 2.2.2 Os processos denominados de ágeis................................................................................................ 37 2.2.3 O Processo Unificado – UP.................................................................................................................. 37
Unidade II
3 Modelo Conceitual da UML.................................................................................................................. 43 3.1 Introdução................................................................................................................................................ 43 3.2 Visão geral da UML............................................................................................................................... 43 3.3 Arquitetura da UML.............................................................................................................................. 44 3.4 Modelagem estrutural......................................................................................................................... 45 3.4.1 Classes de objetos.................................................................................................................................... 45 3.4.2 Relacionamentos entre classes de objetos/instâncias.............................................................. 46 3.4.3 Mecanismos comuns.............................................................................................................................. 46 3.4.4 Diagramas da UML.................................................................................................................................. 47
4 Diagrama de classes de objetos da UML.................................................................................... 51 4.1 Introdução................................................................................................................................................ 51 4.2 Associação................................................................................................................................................ 53 4.3 Papéis em associação........................................................................................................................... 55 4.4 Classe de associação............................................................................................................................ 56 4.5 Agregação e composição................................................................................................................... 58 4.6 Generalização/especialização........................................................................................................... 59 4.7 Herança..................................................................................................................................................... 60 4.8 Conceitos avançados envolvendo classes................................................................................... 63
4.8.1 Herança múltipla..................................................................................................................................... 63 4.8.2 Classes abstratas...................................................................................................................................... 65
4.8.3 Polimorfismo (ocultamento de informações).............................................................................. 66 4.8.4 Interfaces tipos e papéis....................................................................................................................... 67 4.8.5 Pacotes lógicos......................................................................................................................................... 67 4.8.6 Objetivos do diagrama de classes..................................................................................................... 68
4.9 Estudo de caso aplicando modelo de classes............................................................................ 68 4.9.1 Descrição do sistema.............................................................................................................................. 68 4.9.2 Requisitos do sistema............................................................................................................................ 69 4.9.3 Modelo de classe do sistema.............................................................................................................. 70
Unidade III
5 MODELAGEM COMPORTAMENTAL (MODELO DINÂMICO).............................................................. 76 5.1 Introdução................................................................................................................................................ 76 5.2 Modelo de casos de uso..................................................................................................................... 77 5.2.1 Diagramas de caso de uso.................................................................................................................... 77
6 Outros modelos comportamentais da UML............................................................................. 91 6.1 Introdução................................................................................................................................................ 91 6.2 Diagrama de atividades...................................................................................................................... 92 6.3 Diagrama de sequência....................................................................................................................... 93 6.3.1 Linha de vida............................................................................................................................................. 95 6.3.2 Ativação....................................................................................................................................................... 95 6.3.3 Autodelegação.......................................................................................................................................... 95 6.3.4 Mensagem.................................................................................................................................................. 95
6.4 Diagramas de estado (máquina de estado)................................................................................ 96 6.4.1 Estado........................................................................................................................................................... 96 6.4.2 Notações...................................................................................................................................................... 96 6.4.3 Evento........................................................................................................................................................... 97 6.4.4 Transição...................................................................................................................................................... 98
Unidade IV
7 MODELAGEM DA ARQUITETURA DE NEGÓCIO..................................................................................103 7.1 Introdução..............................................................................................................................................103 7.2 Modelagem de negócio....................................................................................................................104 7.2.1 Conceitos de negócio...........................................................................................................................105 7.2.2 Extensão de negócio da UML............................................................................................................ 110 7.2.3 Visões de modelos de negócio.........................................................................................................114
7.3 OCL e sua utilização na modelagem de processo de negócio.......................................... 114 7.4 Integração com o desenvolvimento de software................................................................... 116
7.4.1 Processo de desenvolvimento de software.................................................................................116 7.4.2 Arquitetura de negócio e arquitetura de software..................................................................117
8 A modelagem de processos de negócio................................................................................... 119 8.1 Visão Erikson e Penker....................................................................................................................... 119 8.2 A modelagem de processos de negócio com a BPM............................................................122
8.2.1 Objetos de fluxo.................................................................................................................................... 125 8.2.2 Objetos de conexão.............................................................................................................................. 127 8.2.3 Raias (Swimlanes)................................................................................................................................. 129 8.2.4 Artefatos....................................................................................................................................................131
8.3 Conclusão do BPMN..........................................................................................................................133
APRESENTAÇÃO
O objetivo da disciplina Modelagem de Processos é apresentar e conceituar a importância de modelos no desenvolvimento de sistemas de informação. Nela, os alunos terão condições de entender, analisar, desenhar e descrever os principais e mais importantes modelos de desenvolvimento de software, utilizando a linguagem de modelagem UML (Unified Modeling Language), tanto os modelos estáticos como os modelos dinâmicos. A disciplina também apresenta os conceitos e simbologias envolvidos com a modelagem das áreas de negócio, bem como os mapeamentos de negócios por meio da UML e da moderna linguagem de modelagem de negócios BPMN (Business Process Modeling Notation). INTRODUÇÃO
Entre os autores e especialistas envolvidos com os processos de desenvolvimento de software, existe a crença de que, de algum modo, a modelagem pode ser aplicada para facilitar a nossa vida. Desde a década de 1970, os autores especializados em software vêm propondo processos ou metodologias de desenvolvimento de sistemas que, apesar de utilizarem abordagens diferentes, sempre possuem em seu bojo o uso de modelos visuais e descritivos. Isso é fundamentado no fato de que os modelos visuais permitem o entendimento do mesmo assunto por pessoas com conhecimentos e perfis diferentes. A importância desse entendimento torna-se primordial, já que no processo de software temos a participação de pessoas de diversas áreas de uma organização, indo do usuário final de uma área de negócio até o especialista em software e hardware da área de TI. Todavia, ao longo desse tempo, a modelagem de software vem sendo criticada devido à percepção de que a modelagem é uma atividade que precede o desenvolvimento real e que tem como foco a documentação. Isto é, para muitos especialistas, não se deve privilegiar o desenho ao próprio desenvolvimento. Essas críticas vieram principalmente dos defensores dos métodos ágeis, que privilegiam o código em vez da documentação. Outros autores, entretanto, insistem que a modelagem deve ser reconhecida como uma tarefa de desenvolvimento central importante. Quando os modelos são considerados parte das atividades do processo de desenvolvimento e geram artefatos de primeira classe, os desenvolvedores geram menos código convencional, uma vez que abstrações de aplicativo mais poderosas podem ser empregadas. Dessa forma, quando os modelos abrangem as atividades de desenvolvimento, a comunicação entre as pessoas envolvidas pode ser otimizada e a capacidade de rastreamento ativada no ciclo de vida em qualquer direção. A otimização também vem do fato de que os modelos podem ser fontes de reuso tanto dos objetos criados como das descrições que os envolvem. Acredita-se que tornar a modelagem uma corrente predominante dentro da área de desenvolvimento de sistemas de uma organização pode levar a uma economia de recursos e, com isso, aumentar a 7
abrangência de automação no atendimento das necessidades de uma empresa. A automação do processo de desenvolvimento com o uso de geradores de sistemas a partir de modelos construídos tende a ser uma realidade a médio e longo prazos no processo de software. Pode-se citar, dentro dessa realidade, a Microsoft, que emitiu um documento denominado de “Estratégia de modelagem” em 2005, que aborda o desenvolvimento dirigido por modelo dentro de uma iniciativa chamada Fábricas de Software. Existem diversas empresas, órgãos e grupos que adotam e propõem o uso de modelos no desenvolvimento de software. Entre eles, pode-se citar o Object Management Group (OMG), que adotou a linguagem para a modelagem de produtos de software denominada de UML em novembro de 1997. Essa adoção ocorreu em um evento histórico e marcante, pois assinalou a aceitação de uma linguagem padronizada de modelagem de sistemas baseada nas melhores práticas atuais para a análise, o projeto e a construção de software orientado a objetos. A UML, tema central desta disciplina, é a primeira notação que atingiu o consenso entre a maioria dos profissionais, vendedores e acadêmicos como o padrão real para expressar um domínio comercial da solução de software. Entre os autores da UML, temos o americano Grady Booch, que diz que a modelagem deve atingir quatro objetivos para se tornar efetiva em um ambiente de desenvolvimento de software: 1. Ajudar a equipe de projeto a visualizar um sistema como ele é ou pretende ser. 2. Ajudar a especificar a estrutura ou o comportamento do sistema. 3. Proporcionar um modelo que sirva de guia na construção do sistema. 4. Documentar as decisões tomadas pela equipe de desenvolvimento de projeto. A UML precisa desses objetivos para ser efetiva (REED Jr., 2000). Ela é apresentada tanto nos seus modelos estáticos como nos modelos dinâmicos que mostram as estruturas e os comportamentos dos objetos envolvidos em uma determinada aplicação ou software nos modelos da tecnologia orientada a objetos. Na atualidade, outra área de interesse e importante na construção de sistemas fundamentais é a de processos de negócio, que se propõe a mostrar as atividades previamente estabelecidas nas áreas de negócio e determinar a forma como o trabalho é realizado numa organização. Essas atividades de negócio constituem um conjunto de ações relacionadas entre si de forma lógica e coerente, a fim de promover uma saída favorável à organização, em níveis interno e externo. Uma boa modelagem dos processos de negócio leva à implementação de um sistema de informação bemestruturado. 8
A disciplina aborda os conceitos de modelos, a importância da modelagem de sistemas de informação, a tecnologia orientada a objetos e as modelagens UML e BPM no processo de desenvolvimento de software.
9
Modelagem de Processos
Unidade I 1 A Linguagem Unificada de Modelos 1.1 Introdução
Existe uma crença, entre os envolvidos no desenvolvimento de software, de que, de algum modo, a modelagem pode ser aplicada para facilitar as suas vidas. Todavia, ao longo do tempo, a modelagem de software vem sendo criticada devido à percepção de que é uma atividade que precede o desenvolvimento real e que tem como foco a documentação. Outros autores insistem que a modelagem deve ser reconhecida como uma tarefa de desenvolvimento central importante e não uma atividade focada principalmente em documentação. Quando os modelos são considerados artefatos de desenvolvimento de primeira classe, os desenvolvedores geram menos código convencional, uma vez que abstrações de aplicativo mais poderosas podem ser empregadas. Assim, o desenvolvimento dirigido por modelo é inerentemente mais produtivo e ágil. Além disso, outros participantes no desenvolvimento como analistas de negócios, arquitetos e gerentes de projetos, irão reconhecer a modelagem como o que adiciona valor às tarefas pelas quais são responsáveis. Quando os modelos abrangem as atividades de desenvolvimento e em tempo de execução dessa maneira, a comunicação entre as pessoas pode ser otimizada, e a capacidade de rastreamento ativada no ciclo de vida em qualquer direção. Acredita-se que, ao tornar a modelagem uma corrente predominante, pode-se alterar a economia do desenvolvimento de softwares e garantir que os sistemas de software atendam às necessidades de uma empresa. De acordo com a Microsoft, em seu documento denominado de Estratégia de modelagem, de 2005, essa abordagem do desenvolvimento dirigido por modelo é parte de uma iniciativa chamada Fábricas de software.
11
Unidade I
Saiba mais Vale a pena ler o artigo de maio de 2005, disponível no site
, que discute a estratégia de desenvolvimento da Microsoft, dirigido por modelos com uma série de perguntas e respostas relativas a esses tópicos e interesses. Esse artigo basicamente pergunta e responde: por que modelagem? Como as DSLs são usadas no desenvolvimento dirigido por modelo? E quanto à UML? E quanto à MDA? O que são fábricas de software? 1.2 Motivação para o uso de modelos
Ainda de acordo com a Microsoft, um modelo deve ser um artefato de primeira classe em um projeto, não apenas uma documentação aguardando para se tornar desatualizada. O autor Senge (1990): 1. Define que modelos são mentais, são pressuspostos profundamente arraigados, generalizações, ou mesmo imagens que influenciam a forma de ver o mundo e de nele agir. Muitas vezes, não estamos conscientes de nossos modelos mentais ou de seus efeitos sobre nosso comportamento. 2. Afirma que o trabalho com modelos mentais inclui também a capacidade de realizar conversas ricas em aprendizados, que equilibrem indagação e argumentação, em que as pessoas exponham de forma eficaz seus próprios pensamentos e estejam abertas à influência dos outros. 3. Os modelos possuem uma sintaxe precisa, geralmente são melhores editados e visualizados com uma ferramenta gráfica e contêm semânticas que determinam como conceitos específicos de domínio mapeiam para outros artefatos de implementação, como: código, estruturas de projeto e arquivos de configuração. 4. Dessa maneira, um modelo se parece muito com um arquivo de código-fonte, e os mecanismos que o sincronizam com outros artefatos de implementação são muito semelhantes a compiladores. 5. Um modelo representa um conjunto de abstrações que dá suporte a um desenvolvedor em um aspecto de desenvolvimento bem definido. 6. Como os modelos podem abstrair e agregar informações de uma série de artefatos, podem dar suporte de modo mais rápido a verificações de consistência e outras formas de análise. 12
Modelagem de Processos
Observação Um modelo de conectividade de aplicativos, por exemplo, poderá suportar validação de protocolo de contrato, análise de segurança ou análise de desempenho. Um modelo é uma representação ou interpretação simplificada da realidade, ou uma interpretação de um fragmento de um sistema segundo uma estrutura de conceitos. Um modelo apresenta “apenas” uma visão ou cenário de um fragmento do todo. Normalmente, para estudar um determinado fenômeno complexo, criam-se vários modelos. Observação Por exemplo, pode-se citar obras da Engenharia civil, tais como, uma grande obra hidráulica, uma ampliação de uma praia artificial ou mesmo uma usina hidrelétrica, não são projetadas sem estudos detalhados em vários tipos de modelos matemáticos de diversas categorias e tipos, como modelos de hidrologia, hidráulica e mecânica dos solos. Modelagem também pode ser vista como a arte de criar moldes tanto em fundição (nesse caso, os de areia), como em calçados e em confecção de peças para o vestuário. No caso dessa última, o molde é obtido por uma das três técnicas básicas: moulage, modelagem geométrica ou simples cópia. Segundo os autores Huckvale e Ould (1993, apud BRANCO, 2007), um modelo aplicado a processos oferece: • Um meio para discussão: o modelo de processos ajuda a situar as questões relevantes ao permitir a abstração do mundo real, salientando os objetos e relacionamentos que são de interesse e ignorando detalhes que possam contribuir para aumentar a complexidade. • Um meio para comunicação: permite que outras pessoas, que não as envolvidas no desenvolvimento do modelo, possam utilizá-lo como base para a sua implementação ou para a concepção de novos modelos. • Uma base para análise: a análise de um modelo pode revelar os pontos fortes e fracos do processo, com especial relevância para os fracos, como ações que acrescentam pouco valor ou são potenciais focos de problemas. • A análise por simulação e animação do modelo permite, ainda, estudar os efeitos que possíveis alterações podem causar em um dado processo. 13
Unidade I • Uma base para concepção de novos processos. • Uma base para melhoria contínua: as sugestões para a mudança podem ser expressas em termos de alterações ao modelo e da sua análise, sendo possível ainda sugerir métricas para avaliar o seu desempenho. • Uma base para controle: quando suficientemente formal para ser automatizado, o modelo pode ser utilizado para controlar a execução do sistema modelado, como em um sistema de gestão de Workflow. • Além de garantir o correto funcionamento, permite efetuar medições quanto ao desempenho do processo. 1.3 Princípios da modelagem de software
A modelagem de sistemas de informação (software) é a atividade de construir modelos que expliquem as características ou o comportamento de um software ou aplicativo, ou de um sistema de software. Na construção do software, os modelos podem ser usados na identificação das características e funcionalidades que o esse deverá prover e no planejamento de sua construção. Frequentemente, a modelagem de software usa algum tipo de notação gráfica e é apoiada pelo uso de ferramentas de apoio denominadas de ferramentas Case. Ferramentas Case (Computer-Aided Software Engineering) é uma classificação que abrange todas as ferramentas baseadas em computadores que auxiliam atividades de Engenharia de software, desde análise de requisitos e modelagem até programação e testes. Podem ser consideradas como ferramentas automatizadas que têm como objetivo auxiliar o desenvolvedor de sistemas em uma ou várias etapas do ciclo de desenvolvimento de software. A modelagem de software normalmente implica a construção de modelos gráficos que simbolizam os artefatos dos componentes de software utilizados e os seus inter-relacionamentos. Uma forma comum de modelagem de programas procedurais (não orientados a objeto) é por meio de fluxogramas, enquanto que a modelagem de programas orientados a objeto normalmente usa a linguagem gráfica de modelos UML. Observação Vale a pena, para quem ainda não conhece ou utilizou uma ferramenta Case, fazer download de uma ferramenta free, tais como a ferramenta JUDE ou a ferramenta Umbrello UML, e com elas verificar 14
Modelagem de Processos uma série de propriedades e facilidades que ajudam na documentação, facilitam a comunicação e ainda aumentam de forma considerável a produtividade dos desenvolvedores de software. Algumas são tão sofisticadas que chegam a gerar código diretamente dos modelos construídos. 1.4 Modelagem e orientação a objetos
De acordo com vários autores, há muito tempo busca-se um padrão de construção de software orientado a objetos e sua representação, à semelhança da planta utilizada por outras áreas da Engenharia, tal como a planta de uma casa ou arquitetura de um prédio da Engenharia Civil. O enfoque tradicional de modelagem para a construção de sistemas de informação baseia-se na compreensão desse sistema como um conjunto de programas que, por sua vez, executam processos sobre dados. O enfoque de modelagem por objetos vê o mundo como uma coletânea de objetos que interagem entre si e apresentam características próprias, que são representadas pelos seus atributos (dados) e operações (processos) (FURLAN, 1998). A figura 1 mostra o enfoque baseado em sistema versus o enfoque baseado em objetos.
Programa
Classe
Processos
Atributos
Dados Operações
Foco em sistema
Foco em objeto
Figura 1 – Sistema vs. objeto
Um programa, no sentido tradicional agora, é um conjunto de objetos que se relacionam para executar as funcionalidades ou processos do sistema aplicativo. Então, o programa é representado por classes; os processos, por operações ou métodos; e os dados, por atributos dos objetos. Essa mudança de enfoque se justifica devido ao fato de que os objetos existem na natureza muito antes de o homem criar os computadores e os seus programas de software. 15
Unidade I Carros, equipamentos, pessoas, bancos etc. apresentam características próprias que podem ser representadas pelos seus atributos e pelos seus comportamentos no mundo real. Furlan (1998) informa que essa abordagem oferece como principais benefícios: • manter a modelagem do sistema e, em decorrência, sua automação o mais próximo possível de uma visão conceitual do mundo real; • servir de base à decomposição e modelagem do sistema nos dados, que é o elemento mais estável de todos aqueles que compõem um sistema de informação; • oferecer maior tranparência na passagem de modelagem para a construção por meio da introdução de detalhes, não requerendo uma reorganização do modelo. Lembrete Embora o termo “orientação a objetos” tenha sido usado de várias formas distintas, deveria sempre sugerir uma associação entre coisas do mundo real e trechos de programas de computador ou objetos. De uma maneira mais informal, objeto pode ser visto ou entendido como uma entidade independente, assíncrona e concorrente. Diz-se que um objeto “sabe coisas”, isto é, armazena dados; objeto “realiza trabalho”, isto é, encapsula serviços; objeto “colabora” com outros objetos por meio de troca de mensagens, para executar as funções finais do sistema, sendo modelado. James Rumbaugh (1994) define orientação a objetos como: [...] uma nova maneira de pensar os problemas utilizando modelos organizados a partir de conceitos do mundo real. O componente fundamental é o objeto que combina estrutura e comportamento em uma única entidade (RUMBAUGH, 1994). 1.5 Por que usar a orientação a objetos?
Dentre as várias razões pode-se citar: • Inconsistência na visão dos modelos: — Diferentemente das outras tecnologias de desenvolvimento, o mesmo conjunto de modelos na OO é utilizado em todo o ciclo de desenvolvimento. 16
Modelagem de Processos — Os objetos são: – Descobertos na fase de análise de sistemas para representar os requisitos do usuário. – Alterado na fase de projeto para incorporar as características do ambiente operacional do sistema. – E finalmente utilizado na fase de construção para subsidiar a implementação nas linguagens OO e nos gerenciadores de banco de dados. — Objetos definidos na análise têm representação direta no código, evidenciando a relação entre a definição do problema e a sua implementação. • Melhor abstração do domínio do problema: — A OO mantém uma forte coesão entre a estrutura e o comportamento dos objetos, e essa é a maneira como a realidade se manifesta. • Facilidade para reusabilidade: — A grande procura da Engenharia de software nos últimos anos foi uma forma, ou um método que possibilitasse o reuso de código, prometida por todos, mas nunca alcançado. — A OO, com a implementação do conceito de generalização e especialização, a partir da herança, possibilitam isto. • Melhor suporte à integridade: — Interação entre os componentes OO é restrita a poucas interfaces que são bem definidas. — A única forma de comunicação entre os objetos se dá por meio de troca de mensagens. • Suporte decorrencial à concorrência: — A sincronização de suas partes pode ser mostrada por meio de diagramas e da passagem de mensagens entre os objetos do sistema. • Uso de herança: — Identifica e aproveita os pontos comuns dos dados e serviços (operações, rotinas, métodos). Herança é sinônimo de reusabilidade. A orientação a objetos oferece modularidade de seus elementos, podendo-se tomar um subconjunto existente e integrá-lo de uma maneira diferente em outra parte do sistema. 17
Unidade I Afirma-se que, dessa forma, uma aplicação (sistema) no universo de objetos consiste de um conjunto de blocos de construção autocontidos e predefinidos que podem ser localizados, reparados ou substituídos. Lembrete Uma das coisas mais importantes da modelagem orientada a objetos está na reusabilidade. As técnicas de orientação a objetos permitem reutilizar muito mais do que o código. Com os modelos orientados a objetos, pode-se reutilizar requisitos, análise, projeto, planejamento de testes, interfaces de usuários e arquiteturas. Praticamente todos os componentes do ciclo de vida da Engenharia de software podem ser encapsulados como objetos reusáveis (YOURDON, 1998). A essência da análise e do desenho orientados a objetos de uma aplicação de software é a descrição de comportamentos. Modelos dinâmicos são utilizados para implementar os comportamentos que atendem às necessidades e metas do usuário. As disciplinas de análise e de desenho com objetos apresentam técnicas utilizadas para separar e encapsular os comportamentos das aplicações de software. Os diferentes modelos elaborados durante a análise e o desenho são utilizados de acordo com a sua natureza: • Modelo dinâmico: descreve os comportamentos exibidos pelo computador, quando esse realiza os serviços solicitados pelo usuário. • Modelo estático: descreve a estrutura lógica do computador, de modo que ele se comporte de maneira adequada, e gerencia as dependências entre as diversas partes lógicas do computador. A modelagem orientada a objetos inicia-se com a análise orientada a objetos (AOO), que estabelece o comportamento fundamental de um sistema, comportamento que pode ser mantido independentemente de como o sistema será construído. Na análise OO, são construídos modelos formais de um sistema de software proposto (semelhante aos modelos em escala de um prédio feitos por um arquiteto ou engenheiro civil), que capturam os requisitos essenciais do sistema. Esse modelo deve ser documentado em uma notação ou linguagem simbólica, de preferência conhecida e testada no mercado de software. Um modelo de AOO retrata objetos que representam um domínio de aplicação específico, juntamente com diversos relacionamentos estruturais e de comunicação. 18
Modelagem de Processos De acordo com Yourdon (1998), o modelo de AOO serve para dois propósitos: primeiro, para formalizar a visão do mundo real dentro do qual o sistema de software será construído; segundo, estabelece a maneira pela qual um dado conjunto de objetos colabora para executar o trabalho do sistema de software que está sendo especificado. Na abordagem AOO, de Edgard Yourdon, existem cinco camadas ou visões, conforme a figura 2, que permitem visualizá-lo de perspectivas distintas. Nome da camada Classes e objetos
Símbolos Bordas da classe Borda da instância (objeto) Atributos
Atributos
Serviços
Conexão entre objetos Mensagens Serviços
Estruturas
Assuntos
Assuntos
Figura 2 – Estrutura de um modelo de AOO
A camada de classes e objetos apresenta os blocos básicos de construção do sistema proposto. Os objetos são abstrações de conceitos do domínio de aplicação do mundo real. O coração de qualquer AOO é o processo denominado de modelagem de informações. Na modelagem AOO, os autores consideram como parte difícil do problema estabelecer o que são as coisas do mundo real. No caso de métodos orientados a objetos, tem sido dada mais ênfase na modelagem de informações como um procedimento formal dentro do processo de Engenharia de software (YOURDON, 1998). A figura 3 apresenta um exemplo de aplicação da modelagem AOO com o uso da notação de Edward Yourdon. Serão representadas as entidades envolvidas em um domínio de prestação de serviços por assinatura, como uma assinatura de tv fechada, uma assinatura telefônica etc. O exemplo apresenta somente alguns atributos e alguns serviços de um domínio de aplicação qualquer. 19
Unidade I
Assinante Id_assinante Det_assinante Id_endereco
Assinatura 1
1
Entrar_assinante Informar_endereco
Id_assinatura Estado_assinatura Detalhes_assinatura
Entrar_assinatura
Figura 3 – Exemplo de uma aplicação da AOO
Após a modelagem completa do sistema com todas as entidades, seus atributos, seus serviços e suas estruturas comportamentais definidas (relacionamentos), deve ser construído o Projeto Orientado a Objetos (POO), como uma extensão do modelo AOO. Na proposta de Edward Yourdon, o modelo POO contém as mesmas cinco camadas e usa a mesma notação do modelo AOO, mas é estendido para conter: componente de interação humana (interface homem x máquina), componente de gerenciamento de tarefas e componente de gerenciamento de dados. O componente de interação humana modela a tecnologia de interface que será usada para uma implementação específica do sistema. O componente de gerenciamento de tarefas especifica os itens operacionais que serão estabelecidos para implementar o sistema. Finalmente, o componente de gerenciamento de dados define aqueles objetos necessários para interfacear com a tecnologia de banco de dados que está sendo usada. Além da abordagem de Edward Yourdon, outros métodos e modelagens orientadas a objetos apareceram desde a década de 1970 até 1995. A seguir, algumas das iniciativas desse período: • Sally Shlaer e Steve Mellor escreveram livros sobre análise e desenho orientado a objetos no final da década de 1980 e início da década de 1990. • Jim Odell e James Martin basearam seus enfoques na longa experiência adquirida por ambos no uso e divulgação da Engenharia da informação. Em 1994 e 1996, lançaram os livros mais conceituais da época. • Peter Coad e Ed Yourdon escreveram livros que propuseram um enfoque de desenho recursivo em 1997, propondo a AOO e o POO. • Jim Rumbaugh liderou uma equipe de pesquisadores nos laboratórios da General Electric, que o levou ao livro sobre métodos chamados OMT (Object Modeling Technique) em 1991. 20
Modelagem de Processos • Grady Booch desenvolveu um método na Rational Software para análise de sistemas intensivos em Engenharia e que foram apresentados em seus livros publicados em 1994 e 1995. • Ivar Jacobson produziu seus livros a partir de sua experiência em sistemas na Ericson e desenvolveu o método OOSE (Object-Oriented Software Engineering), que se tornou a base do processo UP e do processo RUP. Toda a proposta está na procura da independência de tecnologia e, portanto, a busca da reusabilidade. Se um dia for necessário trocar a tecnologia envolvida com as interfaces GUI por outra tecnologia mais atual, seria necessário substituir apenas o componente de interação humana. A história da OO inicia-se no final da década de 1960, com a linguagem Simula, que foi projetada por Kristen Nygaard e Ole-Johan Dahl no centro de computação norueguês, em Oslo. No início da década de 1970, os cientistas da computação Edsger Dijkstra e David Lorge Parnas trabalharam no conceito de programação modular, que é um importante elemento da programação orientada a objetos nos dias de hoje. Também na década de 1970, surge a linguagem Smalltalk: • Uma linguagem de programação orientada a objeto fracamente tipada. Em Smalltalk, tudo é objeto: os números, as classes, os métodos, os blocos de código etc. • Não há tipos primitivos, ao contrário de outras linguagens orientadas a objeto. Strings, números e caracteres são implementados como classes em Smalltalk, por isso essa linguagem é considerada puramente orientada a objetos. • Tecnicamente, todo elemento de Smalltalk é um objeto de primeira ordem. • Os programadores definem classes de objetos em suas aplicações para imitar (ou simular) o mundo real. Essas classes de objeto são organizadas hierarquicamente, de modo que seja possível fazer novos objetos com características de outros objetos, com poucas mudanças. • A linguagem Smalltalk foi desenvolvida por Adele Goldberg e Alan C. Kay. No final da década de 1970, surge a linguagem ADA: • Ada é uma linguagem de programação estruturada, de tipagem estática, é uma linguagem imperativa, orientada a objetos, e é uma linguagem de alto nível, originada da linguagem Pascal e de outras linguagens. • Foi originalmente produzida por uma equipe liderada por Jean Ichbiah, da Companhia Honeywell Bull, contratada pelo Departamento de Defesa dos Estados Unidos durante a década de 1970, com o intuito de substituir as centenas de linguagem de programação usadas pelo DoD. 21
Unidade I • Ada é uma aplicação com compiladores validados para uso confiável em missões críticas, tais como softwares de aviação. Normatizada internacionalmente pela ISO, sua versão mais atual é de 2005. Em meados de 1980, o cientista da computação dinamarquês Bjarne Stroustrup criou a linguagem C++ e, dessa forma, é conhecido como o pai da linguagem de programação C++. Stroustrup também escreveu o que muitos consideram a obra padrão de introdução à linguagem, A linguagem de programação C++, que se encontra na terceira edição. A obra possui revista para refletir a evolução da linguagem e o trabalho do comité de padrões de C++, e inspirou as novas linguagens, tais como a linguagem Java e o C#.
Saiba mais Vale a pena ler o livro de Bertrand Meyer cujo título é Object-oriented Software Construction, que se tornou um clássico na área da tecnologia OO. O livro, apesar de ser de 1988, já apresenta um conjunto de conceitos sobre a reusabilidade, técnicas de projeto, programação orientada a objetos e a aplicação das técnicas OO em outros ambientes de desenvolvimento. 1.6 Conceitos básicos da orientação a objetos
Os objetos podem ser vistos como blocos de construção que, combinados por meio de técnicas apropriadas, produzem um sistema. Blocos de construção Blocos de rotinas/métodos
Técnicas adequadas de análise e projeto
Análise/ Projeto/ Construção
Sistemas Figura 4 – Objetos vistos como blocos de construção
22
Modelagem de Processos A tecnologia OO apresenta diversos conceitos fundamentais para seu entendimento e aplicação (FURLAN, 1998): • Objeto: um objeto é uma ocorrência específica (instância) de uma classe e é similar a uma entidade de dados do modelo E x R ou a uma tabela relacional, somente até o ponto em que representa uma coleção de dados relacionados com um tema em comum. Uma pessoa é um objeto, um veículo é um objeto, um documento é um objeto. Outros conceitos sobre objeto: — Objeto é uma bolha de inteligência que sabe agir numa determinada situação (Steve Jobs). — Objeto é alguma coisa que faz sentido no contexto de uma aplicação, dependente do nível de abstração do desenvolvedor do sistema. — Objetos são a base da tecnologia orientada a objetos. — Objetos podem representar coisas do mundo real: carro, gato, máquinas etc. — Entidades conceituais: conta bancária, compras, pedido etc. — Coisas visuais: polígonos, pontos, retas, letras, formulários etc. — Objeto é um conceito, uma abstração, algo com limites nítidos e significado com relação ao problema em causa (James Rumbaugh). • Abstração: abstração consiste na seleção que se faz de alguns aspectos do problema em questão, ignorando-se outros aspectos. — Qualquer objeto real pode ser abstraído para filtrar seu estado e comportamento. — O estado de um objeto é determinado pelo seu conjunto de atributos (dados), e seu comportamento é definido pelos seus serviços (métodos). – Exemplos de objetos de informática: label, botão, caixa de texto, de diálogo etc. – Exemplos de objetos de negócio: funcionário, departamento, produto etc. • Mensagem: objetos se comunicam a partir da troca de mensagens, isto é, um sinal enviado de um objeto a outro, requisitando um serviço por meio da execução de uma operação do objeto chamado. — A interface lógica entre objetos é feita a partir da passagem de mensagens. 23
Unidade I — As mensagens ocorrem apenas entre objetos que possuem uma associação. — Todo o processamento da OO é ativado por uma implementação de mensagens que reforça o conceito de baixo acoplamento em sistemas orientados a objetos. — A recepção de uma mensagem causa a invocação de uma operação no recebedor (objeto alvo). Esse executa o método da classe que corresponde àquela operação. — Uma mensagem pode tomar várias formas: procedure, passagem de sinal entre “threads” ativas, acionamento específico de um evento etc. — Um determinado objeto, recebendo uma mensagem, executará uma ação específica como resposta, alterando seu estado interno, enviando mensagens a outros objetos, criando novos objetos etc. Objeto cliente para o2
Objeto o1
Objeto o3 Objeto servidor para o2
Mensagem de o1 para o2
Objeto o2 Objeto cliente para o3 01
02
aeronave Objeto aeronave
Flap 1
Flap
Ângulo aterrisar
ajustar ângulo Nome da mensagem
Objeto Flap
Flap ajustado
Figura 5 – Troca de mensagens entre objetos
— A mensagem indica uma solicitação de O1 para O2, “coloque o flap num ângulo x!” — Essa é uma mensagem imperativa. — O objeto 02 responde que está tudo ok. Na OO, os parâmetros de chamada e resposta também são chamados objetos (tudo é objeto). 24
Modelagem de Processos • Polimorfismo: é o poder que uma operação de um objeto tem de assumir vários comportamentos dependendo da chamada recebida, tratando e devolvendo respostas específicas ao chamador. — Exemplo: uma classe possui um atributo saldo que pode variar de acordo com o objeto chamador. Pode ser saldo do correntista, saldo da poupança, saldo do fundo de ações, saldo de renda fixa etc. — Então, a operação “buscar_saldo” vai buscar o saldo dependendo do tipo ou parâmetro da chamada, tendo várias lógicas diferentes para um mesmo comportamento denominado “buscar_saldo”. • Classe: classe é uma coleção de objetos que podem ser descritos com os mesmos atributos e as mesmas operações. — Representa uma idéia ou um conceito simples e categoriza objetos que possuem propriedades similares, configurando-se em um modelo para a criação de novas instâncias. — É uma abstração das características comuns a um conjunto de objetos similares. — A classe pode ser pensada como sendo um tipo abstrato de dados. — Conjunto de objetos com propriedades semelhantes, mesmo comportamento (operações, métodos), mesmos relacionamentos com outros objetos e mesma semântica em um domínio de aplicação. — É como se fosse um molde para criação de objetos. — A linguagem Java é um conjunto de classes. Por exemplo: Panel, Label etc. Se o objeto “O” pertence à classe “C”, dizemos que: – “O” é uma instância de “C”; ou – “O” é um membro da classe “C”; ou – “O” pertence a “C”. — Quando queremos ser precisos e nos referirmos a uma coisa exata, usaremos “instância de objeto”. — Para nos referirmos a um grupo de coisas semelhantes, usaremos “classe de objetos”. — Os objetos de uma classe compartilham um objetivo semântico comum, além dos requisitos de atributos e comportamentos. 25
Unidade I Classe Cavalo
Classe Celeiro
Figura 6 – Exemplo de classe de objetos
— Embora um celeiro e um cavalo tenham ambos um preço e uma idade, podem pertencer a classes diferentes. — Caso sejam vistos, no problema, apenas como bens contábeis, poderiam pertencer à mesma classe. • Herança: é a capacidade de um novo objeto tomar atributos e operações de um objeto existente, permitindo criar classes complexas sem repetir código. A nova classe simplesmente herda seu nível base de características de um antepassado na hierarquia de classe. — O propósito principal do uso de herança é construir estruturas que possam ser estendidas em muitas formas diferentes. Esse enfoque pragmático pode-se completar considerando os propósitos de reusabilidade a vários níveis e os propósitos de ordem conceitual. — A reusabilidade é uma das metas mais prezadas que os produtos de software pretendem atingir. O termo reusar tem o significado de poder usar um elemento numa situação diferente da original para o qual foi criado, reduzindo e simplificando esforços (MATICH e CARVALHO, 1992). — A herança tem implicitamente um propósito de reusabilidade, já que proporciona uma forma de reaproveitar características capturadas por componentes, seja na forma de objetos, tipos ou classes. • Atributo ou propriedade: característica particular de uma ocorrência da classe, por exemplo: o aluno possui nome, sexo, data de nascimento, número de registro, telefone etc. — Característica que um objeto possui. Exemplo: nome, cor, altura, data de nascimento etc. — Conjunto de propriedades de um objeto que definem o seu estado. – Propriedades estáticas: mantêm o mesmo valor durante toda a sua existência (exemplo: data de nascimento de uma pessoa). – Propriedades dinâmicas: podem ter valores que variam com o passar do tempo (exemplo: salário de um funcionário). • Encapsulamento: combinação de atributos e operações em uma classe. Exemplo: classe “aluno”, com atributo “nome” e operação “altera_nome_aluno”. 26
Modelagem de Processos — É a capacidade que possuem os objetos de incorporar tanto as estruturas de dados que os determinam, como as operações aplicáveis a essas estruturas em único bloco de organização e só permitir o acesso a elas por meio de métodos determinados. — Vantagens do encapsulamento: – Esconder (ocultar) a complexidade do código. – Não é necessário conhecer como a operação é feita para poder utilizá-la, o código é oculto do usuário. – Proteger os dados, permitindo o acesso a eles apenas a partir de métodos, evita que seus dados sejam corrompidos por aplicações externas. • Generalização: atributos e operações comuns, compartilhados por classes em uma hierarquia “pai-e-filho”, ou superclasse e subclasses, ou classe “pai” e classes “filho”. • Instância de classe: uma ocorrência específica de uma classe. É o mesmo que objeto. “José Carlos Filho” é uma instância da classe aluno, já que o “José Carlos Filho” é aluno cadastrado no sistema acadêmico da escola. — Classes fabricam instâncias sob requisição. Esse processo é chamado instanciação.
Um objeto Aeronave Uma classe
Outro objeto Instanciação
E outro objeto Figura 7 – Instanciação
— O projetista/programador cria a classe. Em tempo de execução, a classe pode ser solicitada para criar novos objetos. — Uma classe possui dados/atributos ou variáveis (programação), serviços/operações ou métodos (programação). – Exemplo: quantidade de carros é um atributo de classe da classe carro. Cada atributo de classe possui um único valor para o conjunto de objetos da classe. 27
Unidade I — Uma instância (um membro) de uma classe também possui: dados/atributos ou variáveis de instância e operações/métodos de instância. – Exemplo: cor, peso e ano de fabricação são atributos de instância da classe “carro”. — Cada atributo de instância possui um valor para cada instância de objeto. O nome de um atributo é único dentro de uma classe. — O agrupamento de objetos em classes permite a abstração de um problema. — As definições comuns e as operações de cada instância são descritas somente uma vez na classe, e os objetos da classe podem beneficiar-se da reutilização das definições armazenadas. • Operações: lógica contida em uma classe para designar-lhe um comportamento. Exemplo: calcular a idade de um aluno dada a sua data de nascimento. — Operação é uma função ou transformação que pode ser aplicada a objetos ou por esses a uma classe em uma determinada situação. – Exemplo: alterar sua cor, mostrar uma janela, debitar um valor, aceitar o crédito de um cliente. — Todos os objetos da classe compartilham as mesmas operações. — Método é a implementação de uma operação para uma classe. — O ato de invocar um método também é chamado de “passar uma mensagem para o objeto”. — Toda classe possui um método denominado “construtor”: atribui valores às propriedades de um objeto quando esse é criado. É o método de inicialização de um objeto instanciado. — Em Java o método construtor possui sempre o mesmo nome da classe. • Subclasse: característica particular de uma classe. Exemplo: classe “animal”, subclasses “gato”, “cachorro” etc. 2 a linguagem unificada de modelos (uml) 2.1Introdução
Antes da UML, havia uma diversidade imensa e improdutiva de abordagens de modelagem, e sua convergência na UML 1.0 foi um passo à frente significante na utilização de modelos no desenvolvimento de software. Cada desenvolvedor usava a abordagem do autor de sua preferência, que nem sempre convergiam suas opiniões em torno do tema. Outro problema era a proliferação de ferramentas gráficas específicas 28
Modelagem de Processos para uma determinada notação para uma metodologia OO também específica e, na maioria das vezes, proprietárias. Ivar Jacobson, Grady Booch e Jim Rumbaugh, em 1995, tomaram a iniciativa de unificar os métodos OOSE (Object Oriented Software Engineering), o método Booch’93 e o OMT (Object Modeling Technique) e deram o nome de UML. UML significa Unified Modeling Language e é uma ferramenta para modelagem de sistemas de todas as complexidades (MEDEIROS, 2004). Lembrete UML significa Unified Modeling Language (Linguagem Unificada de Modelos) e é uma ferramenta para modelagem de sistemas de todas as complexidades, (MEDEIROS, 2004). Em 1999, na versão 1.3, a UML passou a ser mantida pela OMG (Object Management Group), que é um grupo americano responsável pela padronização do uso da orientação a objetos nos Estados Unidos. A UML firma-se então no mercado e passa a ser um padrão internacional para a especificação e modelagem de sistemas aplicativos em todas as áreas de abrangência da área de informática ou TI (Tecnologia da Informação). A finalidade da UML é proporcionar um padrão para a especificação e arquitetura de projetos de sistemas, desde os aspectos conceituais até as soluções concretas, tais como, as classes de objetos, esquemas de banco de dados e componentes de software reusáveis (BOOCH; RUMBAUGH e JACOBSON, 1999). A UML foi criada para ser independe de processo de software. Os desenvolvedores podem pegar alguma coisa da UML que seja apropriado para seu próprio tipo de projeto e para seu próprio processo, usando a UML para registrar os resultados de suas decisões de análise e design. Lembrete A garantia de ser um padrão internacional levou a UML a ser adotada pela OMG que especifica e mantém o metamodelo UML. A especificação da UML, na OMG, é definida usando-se uma abordagem de metamodelo, (isto é, um metamodelo é usado para especificar o modelo que compreende a UML), que adota técnicas de especificação formal. Por outro lado, enquanto essa abordagem usa o rigor de um método formal de especificação, também oferece a vantagem de ser mais intuitivo e pragmático para a maioria dos implementadores e praticantes. 29
Unidade I O metamodelo da UML foi projetada com os princípios de design flexível, tendo em mente o seguinte: • Modularidade: o princípio da forte coesão e baixo acoplamento é aplicado para a construção em pacotes, que permitem organizar recursos em metaclasses. • Camadas: o conceito de camadas é aplicado para o metamodelo UML. • Particionamento: o particionamento é usado para organizar as áreas conceituais dentro de uma mesma camada. • Extensibilidade: a UML pode ser estendida de duas maneiras: — Um novo dialeto da UML pode ser definido por meio de perfis para personalizar o idioma para plataformas específicas (por exemplo, (J2EE/EJB, .NET / COM +) e domínios (por exemplo, finanças, telecomunicações, aeroespacial). — Uma nova linguagem relacionada à UML pode ser especificada por reutilizar parte do pacote e bibliotecas de “InfraEstrutura” dessa. • Reutilização: a biblioteca do metamodelo é flexível para permitir que seja reutilizada para definir o metamodelo UML, bem como outros metamodelos arquitetônicos relacionados, tais como, o Meta Object Facility (MOF) e o Common Warehouse Metamodel (CWM). A infraestrutura da UML é definida pela biblioteca de “InfraEstrutura” UML, pertencente e definida pela OMG. A OMG é uma associação internacional, aberta, sem fins lucrativos e um consórcio da indústria de computador desde 1989. Qualquer organização pode participar da OMG e dos processos de definição das normas. A política da OMG garante que todas as organizações, grandes e pequenas, tenham uma voz eficaz no seu processo. A associação inclui centenas de organizações, sendo metade de softwares finais e a outra metade representando praticamente todas as organizações da indústria de computadores. Quando metamodelamos, primeiramente distinguimos entre metamodelos e modelos. Um modelo deve ser instanciado a partir de um metamodelo que, por sua vez, pode ser usado como um metamodelo de outro modelo de forma recursiva. Um modelo normalmente contém os elementos do modelo. Esses são criados instanciando-se os elementos do modelo a partir de um metamodelo. O papel típico de um metamodelo é definir a semântica de como os elementos do modelo em um modelo podem ser instanciados. Como exemplo, considere-se a figura 4, em que as metaclasses “Classe” e “Associação” são ambas definidas como parte do metamodelo UML. 30
Modelagem de Processos Essas são instanciadas em um modelo de usuário ou desenvolvedor, de modo que as classes “Pessoa” e “Carro” são as duas instâncias da metaclasse “Classe”, e a associação entre as classes é um exemplo da metaclasse “Associação”. A Figura 8 mostra todos os relacionamentos entre o metamodelo e o modelo do sistema que está sendo desenvolvido. Metalmodelo UML
Classe
Associação
“InstânciaDe” Modelo do sistema
Pessoa
Carro
Figura 8 – Exemplo de metamodelagem (note que todos os relacionamentos são mostrados no diagrama)
A semântica da UML define o que acontece quando o usuário define os elementos que são instanciados em seu modelo.
Saiba mais Na atualidade, a UML encontra-se na versão 2.3 e é composta de 13 diagramas. A especificação formal da UML 2.3 pode ser encontrada no endereço . Quadro 1 – Diagramas da UML
Diagramas
Número
UML 1.X
UML 2.3
1
Atividade
Atividade
2
Caso de uso
Caso de uso
3
Classe de objetos
Classe de objetos
4
Objetos
Objetos
5
Sequência
Sequência
6
Colaboração
Comunicação
7
Estado
Estado
8
Componentes
Componentes
9
Implantação
Implantação
10
-------------
Pacotes
11
-------------
Interação
12
-----------
Tempo
13
----------
Estrutura composta
31
Unidade I A proposta da UML não é dizer como se deve fazer um software, mas sim proporcionar formas ou maneiras que podem ser utilizadas para representar um software de acordo com a fase do desenvolvimento. Ela propõe modelos para a fase de especificação, outros modelos para a fase de design e modelos para o momento de se definir as lógicas dos programas ou transações. Todas essas formas ou modelos obedecem às regras e fundamentos da orientação a objetos na construção de softwares. Conforme Medeiros (2004), apesar da definição dos três amigos, pode-se dizer que a UML é uma forma de comunicar uma idéia, e busca um padrão para a ciência da computação com relação à comunicação de pessoas da área, e não uma linguagem de computador. A UML não é um processo de desenvolvimento, tais como, o modelo cascade, ou o modelo RUP (Rational Unified Process), ou o processo ágil SCRUM. É uma linguagem de comunicação que pode ser utilizada em qualquer processo de software dentro de seu ciclo de vida. Hoje, é uma linguagem de modelagem bem definida, expressiva, poderosa e geralmente aplicável a diversos tipos de sistemas, dos mais simples até os mais complexos. Além disso, a UML é não proprietária e aberta a todos. Com a aprovação da UML em novembro de 1997 pela OMG, a guerra de métodos OO havia chegado ao seu final. De acordo com a UML, ela pode ser usada para: • Mostrar as fronteiras de um sistema e suas funções principais. Aqui se introduziu os conceitos de atores e casos de uso. • Ilustrar a realização de casos de uso com diagramas de interações. • Representar uma estrutura estática de um sistema utilizando diagramas de classes. • Modelar o comportamento de objetos com diagramas de transição de estado. • Revelar a arquitetura de implementação física com diagramas de componentes e de implantação (deployment). • Estender sua funcionalidade a partir de estereótipos. 2.2 A UML e o Processo Unificado
Para se falar de um processo de software, é necessário alguns conceitos envolvidos com a Engenharia de software. 32
Modelagem de Processos 2.2.1 Engenharia de software e processos de software Mas o que é a Engenharia de software? A Engenharia de software pode ser conceituda como: • Uma disciplina de Engenharia voltada para todos os aspectos da produção de software de qualidade. • A Engenharia de software estuda processos, modelos e metodologias de desenvolvimento, a gerência de projeto de software, investigação de novos métodos, ferramentas e teorias correlatas, tais como, a qualidade e a produtividade. • Envolve a escolha seletiva de métodos e ferramentas adequados para o atendimento de um determinado contexto (restrições) de sistema de computação. • Abrange todo o ciclo de vida do software, desde a especificação inicial do sistema até sua operação e manutenção. A Engenharia de software está baseada em pilares que lhe dão sustentação. A figura 9 mostra um esquema dessa visão da ES. Engenharia de software(s)
Processos/ guias/práticas/ metodologias
Técnicas métodos métricas
Ferramentas
Qualidade/ produtividade
Gerência governança
Figura 9 – Pilares da Engenharia de software
O estudo dos métodos/técnicas/métricas definem a sequência, a simbologia e os padrões em que as atividades devem ser aplicadas no desenvolvimento e manutenção de software. Com relação às ferramentas, a ES estuda e propõe a automatização dos métodos e técnicas. Essas ferramentas de software são chamadas de ferramentas Case (Computer Aided Software Engineering). A qualidade pode ser definida como um conjunto de modelos que apoiam o processo de desenvolvimento na construção de softwares de qualidade. Com as ferramentas, procura-se também a melhoria da produtividade das equipes de desenvolvimento. A gestão/gerência/governança inclui o planejamento de projetos, controle dos projetos, alocação de recursos, cronogramas e indicadores que apoiem na busca da garantia da qualidade dos produtos confeccionados e no alinhamento da área de TI com as estratégias empresariais. 33
Unidade I Dentro dessa abrangência da ES, um dos aspectos mais importantes é o estudo dos processos envolvidos com o software.
Saiba mais A Engenharia de Software é uma disciplina que é adotada nos cursos de Ciência da Computação, Sistemas de Informação e Engenharia da Computação e cobre todo ciclo de vida de um sistema ou software . Os principais livros adotados pelos cursos são: Engenharia de software, de Roger. S. Pressman, editado no Brasil McGraw Hill; o livro Engenharia de software, de Ian Sommerville, editado pela Addison-Wesley; o livro Engenharia de software – teoria e prática, de James F. Peters e Witpçd Pedrycz, editado pela Editora Campos; e o Livro Engenharia de software fundamentos, métdos e padrões, de Wilson de Pádua Paula Filho, editado pela LTC. Mas, o que é um processo de software? • Um processo de software é um conjunto estruturado de atividades (ou fases) necessárias para produzir um produto de software. • Um processo de software completo abrange as grandes fases de especificação, design ou projeto, a implementação e a manutenção ou evolução do software. • Os processos de software são organizados segundo diferentes modelos de desenvolvimento. Quais são os modelos ou processos de software mais conhecidos? • Ao longo do tempo, desde a década de 1960, a Engenharia de software desenvolveu diferentes representações abstratas das fases de um processo de software e suas interdependências. • Os modelos mais representativos e utilizados na Engenharia de software são: — Modelo cascata (ou clássico): – O paradigma do ciclo de vida clássico ou cascade demanda uma abordagem sistemática e sequencial para o desenvolvimento de software. – Começa em termos de sistema e progride por meio da análise, design, codificação, teste e manutenção. 34
Modelagem de Processos – A figura 10 mostra um esquema visual do modelo cascade ou cascata. Engenharia de Sistemas Análise
Design Codificação Teste Manutenção
Figrura 10 – Ciclo de vida clássico
– Todavia, os projetos reais raramente seguem um fluxo sequencial que o modelo propõe. Ocorrem interações, voltas a níveis anteriores, provocando problemas na aplicação do paradigma clássico. – Frequentemente, os usuários têm dificuldade de estabelecer explicitamente todos os requisitos do software, acompanhados das incertezas naturais que existem no início de muitos projetos. – Os usuários tem que ser muito pacientes. Uma versão do software somente estará disponível quando todo o sistema for definido e desenvolvido. Qualquer alteração pode ocasionar um desastre no desenvolvimento do sistema. – Esses problemas são reais, porém o paradigma do ciclo clássico de software tem um definitivo e importante lugar na Engenharia de software, pois ele proporciona um modelo real para o uso dos métodos para analisar, projetar, codificar, testar e manter softwares. — Espiral: – O modelo espiral para a ES foi desenvolvido para abranger as melhores características do ciclo clássico, adicionando um novo elemento chamado análise de risco. – O modelo apresenta quatro grandes atividades: – Planejamento: determinação dos objetivos, alternativas e requerimentos. – Análise de risco: análise das alternativas e identificação e resolução dos riscos. 35
Unidade I – Engenharia: desenvolvimento do próximo nível do produto. – Avaliação do cliente: aceite dos resultados da Engenharia. – O modelo espiral desenvolve o software passo a passo. Cada novo ciclo pressupõe um maior detalhamento do software, sua construção por meio ou não de prototipagem e um uso real para aceite dos usuários. – A cada final de ciclo e início de outro, os riscos são avaliados e o projeto pode ser ou não cancelado. O número de ciclos não pode ser alto, pois poderia colocar em risco o modelo. – O ciclo final é utilizado para incorporar a parte de segurança, perfomance e garantias de qualidade ao software. – O modelo espiral segue os conceitos da iteratividade ao longo do desenvolvimento de um aplicativo ou projeto de software. Observação Todos os modernos processos de software, inclusive os métodos ágeis, consideram a iteratividade e a liberação parcial de um projeto em suas propostas metodolóicas, conceitos oriundos do modelo espiral. — 4GL – técnicas de quarta geração: – O termo “técnicas de quarta geração” (4GL) abrange um conjunto de ferramentas de software que possuem alguma coisa em comum. – Permitem ao desenvolvedor especificar algumas características do software em alto nível de abstração e então geram automaticamente códigos fontes baseados nas definições. – Os principais ambientes que suportam o paradigma 4GL são: linguagens não procedurais para pesquisas em banco de dados, geradores de relatórios, manipuladores de dados, definidores de telas interativas, geradores de código, geradores de gráficos, arquitetura MDA etc. – Idêntico aos outros paradigmas, o 4GL começa com a especificação dos requisitos junto aos usuários, que deverão ser transportados para um prototipador. Os códigos gerados deverão ser testados e aprovados para que o sistema possa ser considerado pronto. – As técnicas de quarta geração têm se tornado uma parte importante da ES, principalmente na área de sistemas de informação gerenciais. O que se ve é uma diminuição cada vez maior no uso de métodos tradicionais no desenvolvimento de sistemas, e o crescimento no uso das técnicas de quarta geração. 36
Modelagem de Processos 2.2.2 Os processos denominados de ágeis Os processos ágeis ou a modelagem ágil é um processo baseado nas práticas que descrevem como um modelador ágil deve agir. A motivação é devido às estratégias atuais ou clássicas de modelagem que, muitas vezes, não se mostram funcionais ou são consideradas muito pesadas e burocráticas. Em um extremo, a modelagem não existe; do outro, se produz modelagem em excesso. De acordo com Scott W. Ambler, a modelagem ágil se propõe a encontrar um meio termo, o qual permita uma modelagem suficiente para explorar e documentar um sistema de modo eficaz, mas não a ponto de tornar isso um fardo e fatalmente torná-lo um fracasso. As técnicas da modelagem ágil podem e devem ser aplicadas por equipes de projetos que desejam empregar uma estratégia ágil de desenvolvimento de software. Os principais frameworks ou modelos ou métodos ágeis da atualidade são: XP (Xtremme Programming), SCRUM, Crystal, AUP (Ágile Unified Process), ICONIX etc.
Saiba mais Roger S. Pressman, em seu livro Engenharia de software (6ª ed., 2006), nas páginas 59 a 76, faz uma abordagem sintética sobre os métodos ágeis que ele denomina de desenvolvimento ágil, que se inicia com a discussão do que é agilidade, passa pelos conceitos de um processo ágil e apresenta os principais modelos ou métodos ágeis em uso no âmbito internacional, tais como: a Extreme Programming (XP), o Scrum, o Crystal, o FDD (Desenvolvimento Guiado por Características) e a Modelagem Ágil. 2.2.3 O Processo Unificado – UP O processo unificado UP (Unified Process) é um processo de software composto por quatro fases: a fase de concepção, de elaboração, de construção e de transição. O processo unificado, que depois foi extendido para o processo RUP (Rational Unified Process), é todo baseado na UML cujos diagramas e modelos cobrem praticamente todo o ciclo de desenvolvimento desses modelos. A figura 11 mostra um diagrama criado por Scott W. Ambler que mostra, na vertical, as fases da UP e, na horizontal, as disciplinas aplicadas nas fases. 37
Unidade I Phases Inception
Elaboration
I1
E1
Construction
Transition
Model Implementation Test Deployment Configuration management Project management Environment C1 C2
Cn
T1
T2
Figura 11 – A UP vista sob a ótica dos modelos ágeis proposta por Scott W. Ambler
A fase inception seria a fase de concepção, a fase Elaboration seria a fase de elaboração, a fase Construction é a fase de construção e a fase Transition é a fase de transição. Na fase de concepção, se definem os requisitos do software e se avalia a tecnologia necessária para uma solução aderente às necessidades do cliente. Nesse ponto, também é importante que sejam considerados os riscos principais envolvidos com o software a ser desenvolvido. Diversos diagramas e modelos da UML (disciplina Model) podem ser utilizados nessa fase, sendo o mais importante modelo de casos de uso em um nível mais abstrato, já que não se pode demorar muito para se fazer uma proposta comercial e técnica ao cliente envolvido. Na fase de elaboração, na qual para a UP se detalham os requisitos, a UML apóia com diversos diagramas e modelos (disciplina Model), tais como: o modelo de casos de uso com os cenários detalhados, diagrama de atividades (para especificações visuais de lógicas mais complexas), diagramas de estado, diagrama de classes em nível de domínio e outros que se fizerem necessários para deixar as especificações suficientes para a implementação. A fase de construção é quando se pensa em protótipos, em banco de dados e lógicas de programação. A UML, nessa fase, contribui com os diagramas de sequência, comunicação, tempo, pacotes, implantação e componentes. Se o processo é iterativo e incremental, no qual o software não é liberado todo de uma única vez, mas desenvolvido e liberado em pedaços, a fase de construção consiste de muitas iterações, em que constrói-se software, testa-se e faz-se a integração que satisfaça um conjunto de requisitos do projeto. Já na fase de transição, estamos falando dos testes e homologação, dos quais a UML não possui diagramas ou modelos de suporte diretamente. 38
Modelagem de Processos
Resumo Este capítulo apresentou um histórico e conceitos da modelagem de software e o histórico da linguagem de modelos UML. Modelar sistemas é a capacidade de simplificar a complexidade inerente aos sistemas de informação. A construção de modelos permite se enxergar o todo antes de se iniciar a construção ou programação propriamente dita. Modelar significa desenhar e pensar antes de fazer. Permite a passagem de conhecimento para outras pessoas que saibam ler os desenhos e as plantas do sistema. Significa, no final, que os sistemas fiquem menos dependentes de pessoas e passem a ser uma propriedade coletiva. Bom para os profissionais e bom para as empresas de software. É importante salientar que a UML é uma linguagem de modelagem, não uma metodologia de desenvolvimento de software. A UML define uma notação e um metamodelo. A notação é o material gráfico visto em modelos, é a sintaxe da linguagem de modelagem. Ainda sobre a tecnologia orientada a objetos: • As técnicas baseadas em objetos simplificam o projeto de sistemas complexos. • A tecnologia de objetos visualiza os sistemas como uma coleção de objetos, cada um deles em um determinado estado, dentre muitos estados existentes. • A revolução na indústria de software indica um movimento em direção a uma era em que os softwares serão montados a partir de componentes reutilizáveis. • Os componentes serão criados a partir de componentes existentes, e serão criadas grandes bibliotecas desses componentes. 39
Unidade I • Novamente, discute-se com bastante veemência o conceito das caixas-pretas, cujo interior não enxergamos, apesar de sabermos o que elas fazem ou produzem. • As técnicas baseadas em objetos sozinhas não podem prover a magnitude da mudança necessária. Elas têm de ser combinadas com outras tecnologias. • As tecnologias ditas otimizadoras são: — ferramentas Case; — programação visual; — geradores de código; — repositório central de dados e módulos/componentes; — metodologias baseadas em objetos; — banco de dados orientado a objetos; — linguagens não procedurais; — métodos formais baseados na matemática; — tecnologia cliente-servidor, aplicativos orientados a serviços (SOA); — bibliotecas de classes que maximizem a reusabilidade; — abstração de modelos mais próximas do mundo real. Exercícios Questão 1. Os autores que trabalham os conceitos envolvidos com os objetivos da Engenharia de software afirmam que ela é a aplicação de teoria, modelos, formalismos, técnicas e ferramentas da ciência da computação e áreas afins para o desenvolvimento sistemático de software . Ainda de acordo com os autores, o desenvolvimento de software que utiliza modelos para representar a realidade se torna mais produtivo e ágil; aqueles construídos em padrões e simbologias predefinidos permitem que os participantes de um projeto, tanto os analistas como os arquitetos e programadores de software , tenham um mesmo entendimento do problema que está sendo resolvido. Os métodos, as técnicas e as ferramentas também 40
Modelagem de Processos apoiam o gerenciamento do processo de desenvolvimento, devido principalmente a criação de uma documentação formal, que é destinada à comunicação entre os membros da equipe e aos usuários do sistema. Considerando os conceitos sobre o uso de modelos no desenvolvimento de software, analise as afirmações a seguir e assinale a alternativa incorreta: A) O uso de modelos mentais influencia a forma de encararmos o mundo, e o trabalho com modelos permite a realização de conversas ricas em aprendizados. B) Como os modelos possuem uma sintaxe precisa, geralmente são melhor utilizados com o apoio de uma ferramenta gráfica, que, por conter semânticas que determinam como os conceitos específicos de domínio são aplicados, diminuem consideravelmente os erros cometidos no processo de desenvolvimento. C) Como os modelos aplicados na Engenharia de software podem abstrair e agregar informações de uma série de artefatos, eles podem ser utilizados para as verificações de consistência e para a garantia da qualidade. D) Um modelo pode ser considerado um meio de comunicação entre as pessoas envolvidas em um projeto. Também ajuda outros indivíduos, que podem utilizá-lo como base para a sua implementação ou para a concepção de novos modelos. E) Os modelos, no processo de desenvolvimento de software, somente possuem características de comunicação e não conseguem apoiar a equipe na melhoria contínua de seus processos. Resposta: Alternativa E. A modelagem de sistemas de informação ou sistemas de software é uma atividade que, a partir da construção de modelos, consegue explicar as características ou o comportamento de um aplicativo ou de um sistema de software. No processo de desenvolvimento e construção de um software, os modelos podem ser usados na identificação das características e funcionalidades que o software deverá prover e no planejamento de sua construção. Análise das alternativas A) Correta. Quando se defronta com um problema, o homem desenvolve mentalmente uma série de abstrações, as quais permitem o encaminhamento de soluções. Essas abstrações da realidade são denominadas modelos. B) Correta. Os modelos são acompanhados de padrões no seu uso e possuem uma semântica bem definida. As ferramentas denominadas CASE incluem esses padrões, conseguindo, assim, orientar e diminuir os possíveis erros que possam ser cometidos pelas pessoas. 41
Unidade I C) Correta. A qualidade de software pressupõe que os artefatos produzidos no ciclo de desenvolvimento devem ser verificados passo a passo, para que se tenha uma consistência nos produtos realizados. Como os modelos representam graficamente os produtos de software, possibilitam revisões mais cosistentes pelos participantes de seu processo de construção. D) Correta. Como um modelo representa uma abstração de uma realidade, outros podem ser construídos para uma solução de novos aspectos envolvidos com aquela realidade. Um modelo também pode ser detalhado com o uso de novos modelos mais específicos dentro da realidade observada. E) Incorreta. Os modelos no processo de desenvolvimento são utilizados por todos os envolvidos no sistema e são considerados como uma forma de entendimento e apoio às atividades do processo de desenvolvimento, que, a partir da avaliação dos problemas encontrados, pode proporcionar a melhoria do processo. Questão 2. A Orientação a Objetos é considerada um paradigma para o desenvolvimento de software. Baseia-se na utilização de componentes individuais (chamados de objetos), que colaboram para construir sistemas mais complexos. Toda a comunicação ou colaboração entre os objetos é feita por meio do envio de mensagens (um objeto aciona outro objeto para a execução de uma operação e aguarda uma resposta). Um paradigma é um conjunto de regras que estabelece fronteiras e descreve como resolver problemas dentro dessa fronteira. Um paradigma ajuda o homem a organizar a e coordenar a maneira como ele observa o mundo. Considerando-se os conceitos sobre a Orientação a Objetos, analise as afirmações a seguir e assinale a alternativa incorreta: A) Dentro da tecnologia OO, um objeto é alguma coisa que faz sentido no contexto de uma aplicação e representa uma entidade relevante para o entendimento e para a solução de uma necessidade de uma atividade ou ao usuário do sistema. B) Como na OO os objetos se comunicam por meio de mensagens, uma mensagem enviada por um objeto causa a ativação de uma operação (método) no objeto alvo para responder ao chamado do objeto ativador ou chamador. C) Na OO, o conceito de polimorfismo surge quando uma operação de um determinado objeto atua de acordo com as definições específicas de sua funcionalidade. D) Para ser utilizada, uma classe de objeto precisa de um método denominado Construtor, que inicializa o objeto quando ele é instanciado e disponibiliza os recursos para que sejam utilizados pelos métodos ou operações do objeto. E) A UML (Unified Modeling Language) foi desenvolvida na década de 1990 para unificar as diversas correntes existentes no desenvolvimento de software que utilizavam a tecnologia da Orientação a Objetos. Resolução desta questão na Plataforma. 42
MODELAGEM DE PROCESSOS UNIDADE I Questão 2 Resposta correta: alternativa C. Justificativa: os autores originais da UML afirmam que a linguagem de modelos não pretende dizer para os desenvolvedores como se deve fazer um software, e sim proporcionar formas ou maneiras que podem ser utilizadas para representar essa ferramenta de acordo com a fase do desenvolvimento dentro de um processo específico. A UML propõe diversos modelos diferentes que cobrem todo o ciclo de desenvolvimento, desde a especificação até a construção do produto de software. Os modelos propostos na UML obedecem às regras e fundamentos da Orientação a Objetos e não podem ser interpretados como um processo de desenvolvimento, como os modelos cascade e RUP (Rational Unified Process) e o processo ágil SCRUM. A) Correta. Uma aplicação desenvolvida com a Orientação a Objetos é um conjunto de objetos (representados por classes de objetos) que interagem para resolver as funcionalidades do sistema ou aplicação. B) Correta. Os objetos são denominados de cliente e fornecedor. Cliente é o objeto que aciona outro objeto; fornecedor é o objeto que atende a um chamado de outro objeto. O atendimento ocorre por meio das operações do objeto fornecedor, que recebe os parâmetros, executa suas ações e devolve o resultado ao objeto cliente (chamador). C) Incorreta. Polimorfismo é quando uma operação ou método de um objeto atua de formas diferentes dependendo da chamada recebida. Isto é, o comportamento do objeto varia de acordo com o tipo de chamada realizada para a operação do objeto. Polimorfismo quer dizer diversas formas assumidas pelo objeto em um determinado contexto. D) Correta. Sem um método construtor, o objeto não poderia ser inicializado e não se teria a atribuição de valores às propriedades do objeto. E) Correta. Conforme Medeiros (2004), os autores Ivar Jacobson, Grady Booch e Jim Rumbaugh se uniram em 1995 para unificar seus métodos para o desenvolvimento OO e criaram a UML, que se tornou ao longo do tempo a linguagem padrão para a OO.
Modelagem de Processos
Unidade II 3 Modelo Conceitual da UML 3.1 Introdução
O Object Management Group (OMG) adotou a UML em novembro de 1997. Essa adoção ocorreu em um evento histórico e marcante, pois assinalou a aceitação de uma linguagem padronizada de modelagem de sistemas baseada nas melhores práticas atuais para a análise, projeto e construção de software orientado a objetos.
Saiba mais A Object Management Group, ou OMG, é uma organização internacional que aprova padrões abertos para aplicações orientadas a objetos. O Object Management Group foi fundado em 1989. Constantemente, a OMG publica o documento dos padrões e normativos sobre a UML no seu portal cuja URL é: . A UML é a primeira notação que atingiu o concenso entre a maioria dos profissionais, vendedores e acadêmicos como o padrão real para expressar um domínio comercial da solução de software. Grady Booch (2000) diz que a modelagem deve atingir quatro objetivos para se tornar efetiva em um ambiente de desenvolvimento de software: • ajudar a equipe de projeto a visualizar um sistema como ele é ou como ele pretende ser; • ajudar a especificar a estrutura ou comportamento do sistema; • proporcionar um modelo que sirva de guia na construção do sistema; • documentar as decisões tomadas pela equipe de desenvolvimento de projeto (REED JR., 2000). 3.2 Visão geral da UML
A UML não é um modelo de processo/metodologia de software. É uma notação, um mecanismo para “mostrar o problema” de forma a expor a essência do domínio de um aplicativo. 43
Unidade II A combinação da UML com um bom modelo de processo, tais como, o RUP (Rational Unified Process) ou o processo ágil SCRUM, resulta em uma poderosa combinação para a criação de aplicativos bemsucedidos (REED JR., 2000). A linguagem de modelos UML tem dois objetivos: um deles é proporcionar consistência, informando o cliente ou patrocinador do projeto de que o domínio do problema está bem entendido pela equipe de desenvolvedores. O outro objetivo é proporcionar um modelo de consistência para a equipe de implementação (arquitetos e programadores), que assim poderão fazer uma implementação adequada do software. Lembrete Todavia, deve ficar claro que somente os diagramas da UML não conseguem garantir o processo de desenvolvimento. Um bom modelo de processo e um plano adequado do projeto são fundamentais para que o projeto não falhe. Todos os artefatos propostos pela UML são rastreáveis e, se construídos ao longo de um processo de desenvolvimento padronizado na empresa, os modelos podem se completar uns aos outros. Esse elemento da rastreabilidade é fundamental para o projeto. Esses artefatos construídos ao longo do desenvolvimento com a UML servirão como um ponto de controle da qualidade do modelo anterior, já que se completam. Como os modelos UML são interrelacionados na sua criação, é mais fácil identificar quando um componente está faltando ou está incorreto. Todavia, a UML não resolve diretamente alguns aspectos de um projeto e, se necessário, deve-se utilizar outros diagramas auxiliares, como a interface gráfica de usuário (GUI), a distribuição do processo (processamento distribuído) e a distribuição dos dados (BDs distribuídos). 3.3 Arquitetura da UML
Uma arquitetura de sistema de software pode ser descrita por cinco visões interconectadas. Cada visão é uma projeção na organização e estrutura do sistema, focando em um aspecto particular desse. As cinco visões da arquitetura UML são: visão de análise, visão de design, visão de implementação, visão do processo e visão da implantação. Para a UML, o modelo ou visão que interconecta essas visões se dá pelo modelo de caso de uso. A visão de caso de uso de um sistema compreende os que descrevem o comportamento do sistema como visto pelos usuários finais, analistas e testadores. Essa visão não especifica a organização do sistema de software. Na UML, os aspectos estáticos do sistema são capturados no diagrama de caso de uso. 44
Modelagem de Processos Os 13 diagramas da UML estão divididos em três categorias: estático, dinâmico e arquitetural: • Os diagramas estáticos mostram a esturutra do sistema e as responsabilidades. Esses diagramas mostram a estrutura física dos elementos e não envolvem a passagem do tempo. Isto é, eles não mostram a dinâmica das coisas, simplesmente sua organização. Os três principais diagramas estáticos da UML são: o modelo de caso de uso, o modelo de classes e o modelo de objetos. • Um diagrama dinâmico mostra a interação ativa que o sistema suporta e detalha a interação entre os elementos estruturais dos diagramas estáticos. • Essas interações dinâmicas são descobertas nos casos de uso como caminhos executados em resposta a alguns estímulos externos ao sistema. Os diagramas dinâmicos mostram o comportamento pretendido do sistema. Os principais diagramas dinâmicos são: atividades, comunicação, sequência e estado. • Um diagrama arquitetural mostra a realização do sistema em componentes funcionais e executáveis. Eles também diferenciam a localização física da execução e os nós de armazenamento e uma estrutura dentro da qual eles podem interagir. • Os principais diagramas estruturais são: componentes e implantação. 3.4 Modelagem estrutural
Na UML, o principal diagrama que mostra a estrutura de um sistema é o diagrama de classes. Todavia, outros diagramas também permitem visualizar a estrutura do sistema, tais como, o diagrama de pacotes, o diagrama de componentes, o diagrama de objetos e o diagrama deployment (implantação). 3.4.1 Classes de objetos Uma classe de objetos é uma coleção de objetos que podem ser descritos com os mesmos atributos e as mesmas operações. Representa uma idéia ou um conceito simples e categoriza objetos que possuem propriedades similares, configurando-se em um modelo para a criação de novas instâncias (outros objetos). Uma classe de objetos na UML possui três segmentos: nome, atributos e operações. A representação ou notação de uma classe é um retângulo com os três segmentos. Cada classe deve ter um nome que a distingue de outras classes. Um nome é um texto. Uma classe possui diversos atributos. Um atributo é uma propriedade do objeto que descreve a faixa de valores que as instâncias do objeto podem ter. 45
Unidade II O terceiro segmento da classe são as operações. Uma operação é a implementação de um serviço ou funcionalidade que pode ser requisitado de qualquer objeto da classe para afetar o comportamento do objeto. 3.4.2 Relacionamentos entre classes de objetos/instâncias As classes de objetos, no modelo de classes, se relacionam ou se associam de acordo com as necessidades do sistema. Esses relacionamentos são denominados “associação entre classes”. Um relacionamento define as regras da associação que, por seu lado, são impostas pelas regras de negócio da aplicação, sendo modelada. A criação de um objeto, baseado em uma classe, recebe um nome especial: instância. Quando é necessário manipular um determinado objeto, a classe é carregada na memória, e os objetos são instanciados, isto é, são criados na memória e podem ser manipulados. A instanciação de objetos depende da linguagem OO utilizada, mas, em geral, possuem uma função especial que cuida das instâncias dos objetos, denominada construtora. Quando o objeto já não é mais necessário, outra função especial chamada de destrutora da classe elimina as instâncias criadas. Por exemplo: para uma classe funcionário, o objeto tipo funcionario “João Carlos da Silva” seria uma instância na memória. 3.4.3 Mecanismos comuns A UML é feita simplesmente pela presença de mecanismos comuns que garantem a consistência a partir da linguagem, tais como: especificação, adornos e mecanismo de extensibilidade. A especificação refere-se aos padrões das descrições dos componentes dos modelos: como nomear os componentes, como descrever a lógica de um cenário de um caso de uso , e assim por diante. Adornos são itens gráficos e textuais que são adicionados a uma notação de um elemento básico e são usados para visualizar detalhes da especificação do elemento. Por exemplo, no símbolo de nó de um diagrama de implantação, pode ser interessante colocar os componentes executáveis dentro de uma caixa extra do desenho. O mecanismo de extensibilidade da UML permite extender a linguagem de uma maneira controlada. Esse mecanismo inclui estereótipos, valores marcados e restrições. Um estereótipo extende o vocabulário da UML, permitindo que se criem novos tipos de blocos de construção que são derivados de outros existentes, mas especifícos para um determinado problema. 46
Modelagem de Processos 3.4.4 Diagramas da UML Com um modelo, é possível um melhor entendimento dos sistemas que estão em desenvolvimento. Com a UML, pode-se construir modelos a partir de um conjunto de blocos básicos, tais como, classes, interfaces, colaborações, componentes, nós, dependências, generalizações e associações. Lembrete Quando o homem modela qualquer coisa, ele está criando uma simplificação da realidade. A UML propõe 13 diagramas, conforme mostra a quadro 2: Quadro 2 – Diagramas da UML Número
Diagramas
UML 1.X
UML 2.3
1
Atividade
Atividade
2
Caso de uso
Caso de uso
3
Classe de objetos
Classe de objetos
4
Objetos
Objetos
5
Sequência
Sequência
6
Colaboração
Comunicação
7
Estado
Estado
8
Componentes
Componentes
9
Implantação
Implantação (deployment)
10
-------------
Pacotes
11
-------------
Interação
12
-----------
Tempo
13
----------
Estrutura composta
Lembrete Com relação ao ciclo de desenvolvimento de software: • Cada diagrama da UML, ou modelo, pode ser usado em um determinado momento do ciclo de desenvolvimento de software. • Um diagrama da UML deve ser usado para resolver ou mostrar aspectos específicos do problema sendo modelado. • Um diagrama da UML pode ser usado para especificar artefatos diferentes em atividades diferentes do processo de software. Por 47
Unidade II exemplo, o diagrama de atividade pode ser usado para detalhar uma funcionalidade, como mostrar um determinado fluxo do problema que está sendo estudado etc. 3.4.4.1 Diagrama de atividade Os diagramas de atividades são usados para modelar o comportamento de um sistema, e a forma em que esses comportamentos estão relacionados em um fluxo geral desse. O fluxo mostra os caminhos de um processo lógico a seguir, com base em várias condições, processamento simultâneo, acesso a dados, interrupções e outras distinções do caminho lógico. São usados para construir um sistema, um processo, ou um procedimento. 3.4.4.2 Diagrama de caso de uso Um diagrama de caso de uso captura as funcionalidades do sistema e as relações entre os atores e o sistema. Ele descreve os requisitos funcionais do sistema, a maneira pela qual as coisas de fora (atores) interagem no limite do sistema e a resposta desse aos usuários. Lembrete O diagrama de caso de uso, ou modelo de caso de uso, é um dos mais importantes modelos da UML e será detalhado na Unidade 3. 3.4.4.3 Diagrama de objetos Um diagrama de objetos está intimamente relacionado a um diagrama de classes de objetos, com a distinção de que retrata instâncias de objetos das classes e seus relacionamentos em um ponto no tempo. Isso pode parecer semelhante a um diagrama de estrutura composta, que também modela comportamentos em tempo de execução. A diferença é que os diagramas de objetos exemplificam os diagramas de classes estáticas, enquanto que os diagramas de estrutura composta refletem arquiteturas em tempo de execução. Eles são úteis na compreensão de um diagrama de classes complexas, criando diferentes casos em que os relacionamentos e as classes são aplicados. Um diagrama de objeto também pode ser uma espécie de diagrama de comunicação, que também modela as conexões entre os objetos, mas adiciona sequências de eventos ao longo de cada caminho. 48
Modelagem de Processos 3.4.4.4 Diagrama de sequência O diagrama de sequência é um dos quatro tipos de diagrama de interação. Um diagrama de sequência é uma representação estruturada de comportamento com uma série de etapas sequenciais ao longo do tempo. Ele é usado para descrever o fluxo de trabalho, passagem de mensagens. Cada elemento da sequência é organizado em uma sequência horizontal, com mensagens que passam para trás e para frente entre os elementos. Um elemento de ator pode ser usado para representar o usuário que inicia o fluxo de eventos. Elementos estereotipados, como limite, controle e entidade, podem ser usados para ilustrar as telas, os controladores e os itens de banco de dados, respectivamente. Cada elemento tem uma linha pontilhada tronco chamada de linha-de-vida, na qual o elemento existe e, potencialmente, participa das interações. 3.4.4.5 Diagrama de comunicação Um dos quatro tipos de diagrama de interação. Um diagrama de comunicação mostra as interações entre os elementos em tempo de execução da mesma maneira que um diagrama de sequência. No entanto, os diagramas de comunicação são usados para visualizar as relações entre objetos, enquanto os diagramas de sequência são mais eficazes na visualização de processamento ao longo do tempo. Os diagramas de comunicação empregam associações rotuladas e ordenadas para ilustrar o processamento. A numeração é importante para indicar a ordem e a nodificação de processamento. Um esquema de numeração pode ser: 1, 1.1, 1.1.1, 1.1.2, 1.2 e assim por diante. 3.4.4.6 Diagrama de estado (máquina de estado) Os diagramas de estado da máquina eram anteriormente conhecidos como diagramas de estado. Esse diagrama ilustra como um elemento (geralmente uma classe) pode mover-se entre os estados, classificando o seu comportamento de acordo com gatilhos de transição ou guardas de restrição. Outros aspectos do diagrama de máquina de estado ajudam a descrever e explicar os movimentos e comportamentos dos sistemas. 3.4.4.7 Diagrama de componentes Um diagrama de componentes mostra os pedaços de software, controladores embutidos que formam um sistema, sua organização e as dependências. Um diagrama de componente tem um nível maior de abstração do que um diagrama de classes. Geralmente, um componente é implementado por uma ou mais classes (ou objetos) em tempo de execução. 49
Unidade II Eles são blocos de construção, construídos de modo que, eventualmente, um componente pode abranger uma grande parte de um sistema. 3.4.4.8 Diagrama de implantação Um diagrama de implantação (deployment) mostra como e onde o sistema será implantado, ou seja, sua arquitetura de execução. Dispositivos de hardware, processadores e ambientes de software de execução (artefatos do sistema) são refletidos como nós, e a construção interna pode ser representada incorporando nós no desenho. Como os artefatos são alocados para os nós do modelo de implantação do sistema, a alocação é guiada pela utilização das especificações de implantação. 3.4.4.9 Diagrama de pacotes O diagrama de pacotes (pakage) mostra a organização dos elementos de um modelo em pacotes (agrupamentos) e as dependências entre esses pacotes, incluindo pacotes importados e extensões de pacotes. 3.4.4.10 Diagrama de interação (visão geral) Um diagrama geral de interação visualiza a cooperação entre os diagramas de interação para ilustrar um fluxo de controle que serve a um propósito abrangente. Como os diagramas gerais de interação são uma variante de diagramas de atividades, a maioria da notação do diagrama é a mesma, como é o processo de construção do diagrama. Pontos de decisão, forks, junções, pontos iniciais e finais são os mesmos. Em vez de elementos de atividade, no entanto, elementos retangulares são usados. Existem dois tipos desses elementos: elementos de interação e e elementos de ocorrência. 3.4.4.11 Diagrama de tempo Um diagrama de tempo define o comportamento de objetos diferentes dento de uma escala de tempo. Ele fornece uma representação visual da mudança dos objetos, mudando de estado e interagindo todo o tempo. Ele pode ser usado para definir os componentes e softwares embutidos. Também pode ser utilizado para especificar processos de negócio orientados pelo tempo. 3.4.4.12 Diagrama estrutura composta Um diagrama de estrutura composta reflete a colaboração interna de classes, interfaces ou componentes (e suas propriedades) para descrever a funcionalidade do sistema. 50
Modelagem de Processos Eles são similares aos diagramas de classe, exceto pelo fato de que eles modelam um uso específico da estrutura. Um diagrama de estrutura composta é usado para expressar o tempo de execução das arquiteturas, padrões e relacionamentos dos elementos participantes, que não podem ser refletidos por meio de diagramas estáticos. 4 Diagrama de classes de objetos da UML
Entre esses diagramas, o diagrama de classes é considerado um dos principais e será detalhado a seguir. 4.1 Introdução
O diagrama de classes mostra a estrutura estática do sistema por meio de suas classes e objetos e também como eles se relacionam. É considerado por alguns autores como o mais importante diagrama no desenvolvimento orientado a objetos e, portanto, também da UML. Observação A meta na construção de um modelo de objetos é incorporar os conceitos do mundo real que sejam importantes para a aplicação. A figura 12 mostra um exemplo de modelo de classes de objetos na notação da UML.
Mundo real
Realidade de interesse (Observado)
Modelo de objeto Nome da classe de objetos Atributos Operações ( ) Figura 12 – Visão do mundo real x a OO
51
Unidade II A figura 13 mostra um exemplo de diagrama de objetos com um metamodelo de classe, uma classe e duas instâncias da classe “José da Silva” e “Maria Rodrigues”. Nome da classe de objetos
Pessoa
Nome dos atributos
Nome idade
Operações ( )
Mudar_endereço ( )
José da Silva 32
Maria de Tal 26
Objetos com valores da classe pessoa.
O nome da classe (metamodelo) representa o agrupamento de objetos do mesmo tipo. Figura 13 – Exemplo de uma classe e suas instâncias na notação UML
Alguns meios de implementação (linguagens de programação e sistemas gerenciadores de banco de dados) exigem que um objeto tenha um identificador explícito para cada objeto. Esses identificadores explícitos não são obrigatórios em um modelo de objetos. A figura 14 mostra um uso incorreto de identificadores internos.
Pessoa Cod_Pessoa Nome
Pessoa Correto
Nome idade
Figura 14 – Uso incorreto de identificador interno
Os identificadores internos (gerados pelas linguagens) não podem ser confundidos com atributos do mundo real e não devem fazer parte do modelo conceitual. O “número_telefone” e “número_placa_ carro” não são identificadores internos porque têm significado no mundo real. Uma classe sempre deve representar um mesmo assunto, isto é, ela encapsula conhecimentos sobre algo. Não teria sentido colocarmos dados sobre a empresa em que trabalha na classe pessoa. Pessoa e empresa são assuntos diferentes ou objetos diferentes e, portanto, devem estar em classes distintas. Uma classe tem responsabilidade por tudo o que lhe diz respeito. Não é de responsabilidade da pessoa/funcionário incluir ou manter os dados da empresa. Uma classe poder ter visibilidade pública, protegida, privada: • Uma classe pública indica que qualquer outra classe poderá acessar seus atributos e solicitar a execução de suas operações. 52
Modelagem de Processos • Uma classe é denominada de privada quando restringe totalmente o acesso a seus atributos e as suas operações. • Uma classe com visibilidade protegida somente permite a ela e aos seus herdeiros o acesso a seus atributos e suas operações. As operações ou comportamentos de uma classe de objetos recebem e devolvem valores que são passados numa lista de argumentos, dentro de um padrão específico que cada linguagem adota. O diagrama do modelo conceitual deve ser independente da tecnologia, e quando da implementação é que se considera os padrões específicos. A figura 15 mostra um exemplo de chamada de uma operação com a lista de argumentos. Exemplo: mudar_endereço (novo_endereço, ok) Operação
Parâmetro de entrada
Parâmetro de saída
Figura 15 – Exemplo de uma operação e a lista de argumentos
Em um modelo de classes, existem diversas classes do domínio da aplicação que precisam se relacionar dentro das regras de negócio. Elas, quando estão relacionadas, podem trocar mensagens para que uma determinada tarefa que envolve diversos objetos possa ser realizada com sucesso. Os relacionamentos das classes no modelo de classes podem ser de três tipos: associação, agregação e composição e generalização/especialização. 4.2 Associação
Associação é uma relação semântica entre classes. Uma associação acontece quando uma determinada instância de uma classe se associa a uma ou mais instâncias de outra ou da mesma classe. Ligações e associações são os meios para estabelecermos relacionamentos entre objetos e classes. As ligações são conexões entre instâncias de objetos. A figura 16 mostra o metamodelo de associação de classes e um exemplo prático.
53
Unidade II Papel 1 Classe A
Classe B
Papel 2 associação
Pessoa
Empresa
trabalha_para
João da Silva
Telesp
ligação Figura 16 – Exemplo de uma associação entre duas classes. O modelo apresentado é o modelo de objetos no qual o objeto pessoa trabalha para uma empresa
As associações ainda podem ser binárias, unárias, ternárias e assim por diante. Uma associação é dita binária quando duas classes estão envolvidas na associação, conforme mosta a figura 17. tem_capital
Pais
Cidade
0.1
Nome
1
Nome
Figura 17 – Associação binária
Uma associação é dita unária quando o relacionamento de uma classe é consigo própria. A figura 18 mostra um exemplo de associação unária. Uma peça pode compor outras peças maiores, mas também pode ser composta de outras peças menores. Peça
1..* Componente
Composta
0..*
Figura 18 – Um exemplo de associação unária
Uma associação é dita ternária quando três classes fazem parte da associação. Na figura 19, tem-se que um projeto tem várias pessoas trabalhando nele e pode ser implementado em várias linguagens diferentes. A nomeação das associações são opcionais para associações ternárias ou de ordem superior (n-árias). 54
Modelagem de Processos A figura 19 mostra um exemplo de associação ternária. 1..*
Projeto
1..*
Linguagem
1..* Pessoa Símbolo de associação ternária ou de ordem superior Figura 19 – Exemplo de uma associação ternária
4.3 Papéis em associação
A UML possui uma notação específica para representar as regras de uma associação entre os objetos das classes. A notação denomina-se cardinalidade ou multiplicidade e deve ser descrita no diagrama, como mostra a tabela 1. Tabela 1 – Cardinalidades ou multiplicidades das associações entre classes Cardinalidade
Descrição
0..1
Opcional e único
0..*
Opcional e múltiplo
1
Obrigatório e único
1..*
Obrigatório e múltiplo
*
O mesmo que 0..*
2..4
De 2 a 4
1..2,5,7..14
1 e 2, 5 e 7 a 14
Quando se quer ressaltar que um dado elemento da associação deve estar classificado, deve-se utilizar a palavra-chave {ordenado}, como mostra a figura 20. Classe A
Papel 2 Papel 1
{ordenado}
Classe B
Figura 20 – Uso da palavra chave {ordenado}
Quando se quer declarar a visibilidade da associação, deve-se colocar os símbolos em frente ao nome do papel (“+” público, ”#” protegido, “-“ privado). Isso declara a visibilidade da associação em direção àquele papel. 55
Unidade II Por exemplo: na figura 9, se for colocado em frente do papel 1 o símbolo “+”, está declarado que esse papel na associação é de uso público. Quando existir a necessidade de mostrar o sentido da navegação em uma determinada associação, deve-se colocar uma seta na extremidade da associação para indicar a direção suportada pelo modelo. A figura 21 mostra um exemplo do uso da navegação em uma associação entre duas classes de objetos. tem capital
Pais Nome
0..1
Cidade 1
Nome
Figura 21 – Navegação (restrição de acionamento de classes)
A seta indica o sentido em que a navegação é suportada no modelo, dessa forma não é possível operações da classe cidade acessarem as operações da classe país. 4.4 Classe de associação
Em alguns modelos, devido às regras de negócio, torna-se necessária a colocação de atributos em uma determinada associação. Um atributo é uma propriedade dos objetos de uma classe. Como uma associação também é um objeto, é perfeitamente possível colocar nela atributos. Então, um atributo de ligação é uma propriedade de uma associação. A figura 22 apresenta a classe “depto de uma empresa” e a classe funcionário, nas quais ficam os funcionários da empresa. Depto Nome
1
Chefia
Funcionário 0..1
Cod_func nome
Figura 22 – O uso de atributos de associação
A questão que se coloca no modelo é: onde colocar a data de posse da chefia, em departamento ou em funcionário? Todavia, a data de posse é uma propriedade da associação “chefia” e deve pertencer a ela. A data de posse não é propriedade nem do departamento e nem do funcionário. Uma das soluções seria colocar a data em uma das classes associadas. A escolha fica a critério do analista, já que esse atributo não é natural nem para departamento e nem para funcionário. 56
Modelagem de Processos O problema decorrente da colocação dos atributos de ligação em uma das classes ligadas é a flexibilidade futura do modelo. Caso haja qualquer dúvida com relação ao futuro, como regra, cria-se uma “classe de associação”. Como mostra a figura 23, criou-se uma classe nova denominada “classe de associação” para permitir a colocação do atributo específico da associação. A classe de objetos “chefia”, possui atributos próprios e provavelmente operações para tratar esses atributos e as associações. 0..1 Depto
Funcionário
1
Cod_func nome
Nome
Chefia Data_posse
Figura 23 – O uso da classe de associação
A figura 24 mostra outro exemplo de classe de associação para um modelo mais sofisticado. Temos um modelo que mostra uma empresa, seus funcionários e o grau de desempenho desses. Funcionário Nome RG
0..* Trabalha_para
1..*
Empresa Nome Endereço
Endereço Gerencia Grau de desempenho
Trabalha para Salário Cargo Admite_funcionário ( )
Figura 24 – Classes de associação
Note que o grau de desempenho pertence à associação, já que o atributo somente tem sentido enquanto o funcionário ocupa o cargo de gerência. A classe “trabalha para” indica que o salário e o cargo do funcionário são atributos que dependem da empresa em que trabalha, já que o modelo permite que um funcionario trabalhe em mais de uma empresa. 57
Unidade II 4.5 Agregação e composição
Agregação é um tipo especial de associação em que um objeto contém o(s) outro(s). É também chamado de relacionamento “todo/parte”. Agregação é um modo de associação na qual um objeto agregado é feito de componentes. Os componentes fazem parte do agregado. A figura 25 mostra um exemplo de agregação. Uma publicação possui artigos obrigatoriamente no modelo. Isso significa que uma publicação é composta necessariamente de artigos. O diamante vazio indica que a ligação é fraca, já que uma publicação pode existir sem nenhum artigo, mas um artigo não existe sem uma publicação associada. Publicação 1..* 0..* Artigo
Figura 25 – Exemplo de uma agregação entre classes associadas
As agregações incluem explosões das partes e expansões de um objeto em suas partes constituintes. A figura 26 mostra outro exemplo de agregação entre classes de objetos. Empresa
Trabalha_para 0..1
Funcionário 0..*
1 0..* Divisão
1 0..* Departamento
Figura 26 – Exemplo de agregação
Uma empresa é uma agregação de suas divisões, que são, por sua vez, agregações de seus departamentos. Uma empresa não é uma agregação de seus funcionários, uma vez que empresa e pessoa são objetos distintos e independentes.
58
Modelagem de Processos Uma composição é uma agregação forte em que as partes estão fisicamente contidas dentro do todo. Os componentes não podem ser compartilhados por outros compostos. Uma exclusão do todo desencadeia uma exclusão em cascata das partes, portanto, o ciclo de vida das classes em composição coincidem. A figura 27 mostra um exemplo de composição. Livro
1 0..* Capítulo
Figura 27 – Exemplo de composição (associação forte)
A exclusão de um livro acarreta a exclusão de todos os seus capítulos, e a exclusão dos capítulos do livro implica a elimincação do livro. 4.6 Generalização/especialização
A generalização é uma forma de se estruturar a visibilidade de um elemento global com uma visão mais detalhada desse. Isso é feito adicionando características específicas ao elemento na visão detalhada e aproveitando as características gerais. generalização
especialização
Figura 28 – Generalização x especialização
A generalização/especialização pode ser usada para diversos outros modelos da UML, como em diagramas de pacotes e diagramas de casos de uso. 59
Unidade II As classes superiores são chamadas superclasses, e as inferiores subclasses. Tanto a superclasse como as subclasses referem-se às características de um único objeto. Com a generalização, um objeto é simultaneamente instância da superclasse e instância da subclasse.
Trabalha_para
Empresa 0..1
Divisão
Funcionário
Associação de generalização
0..*
Masculino
Feminino
Departamento
Figura 29 – Exemplo de generalização
Uma árvore de generalização é composta por classes que descrevem um objeto. No exemplo da figura 19, a classe funcionário foi especializada em masculino e feminimo, devido a características específicas de cada um, mas o modelo garante que as características comuns estão representadas somente uma vez na superclasse funcionário. Diz-se que masculino é um “tipo_de” funcionário ou masculino “é um” funcionário. Um funcionário ou é masculino ou é feminino. 4.7 Herança
Na UML, herança é um mecanismo por meio do qual uma instância de uma classe assume os atributos e os comportamentos dos objetos de outra classe (antepassados ou antecedentes). Os objetos subordinados herdam atributos e serviços da classe superior. A propriedade herança permite que novas classes sejam construídas pela herança de classes existentes. A figura 30 mostra um exemplo de herança.
60
Modelagem de Processos Aeronave Classe ou superclasse
Jato
Planador Subclasse
Figura 30 – Exemplo de aplicação do mecanismo de herança
No exemplo da figura 30, as classes jato e planador são subclasses de aeronave. As classes subordinadas podem ter atributos e ou métodos próprios. O conceito de herança reforça a extensibilidade característica que sempre se procurou na programação. Uma classe descendente/subclasse não pode omitir ou suprimir um atributo da superclasse, senão não seria uma instância antecessora. As subclasses também são chamadas de classes derivadas ou classes-filho na hierarquia de classes. As classes que ficam mais altas na hierarquia são denominadas de superclasses. Funcionário
Funcionário feminino nome solteira registrar licença maternindade
Funcionário masculino
Figura 31 – Exemplo de herança
Pode acontecer de uma subclasse possuir alguma operação diferente de seu antecessor. Isso é chamado de extensão. Uma subclasse pode restringir atributos do antecessor. Isso é chamado de “restrição”, pois restringe os valores que aquela instância pode assumir. Lembrete O mecanismo de herança se tornou sinônimo de reutilização de código no projeto orientado a objetos. 61
Unidade II A figura 32 mostra um exemplo completo do uso de herança. Equipamento nome fabricante preço peso Bomba
Tanque Volume pressão
Tipo de equipamento
pressão de sucção pressão de descarga taxa de fluxo
Tipo de tanque Tipo de bomba
Tanque esférico Bomba centrífuga
diâmetro
eixo de rotação
Tanque pressurizado diâmetro altura
Tanque de teto flutuante diâmetro altura
Bomba de imersão
Bomba de diafragma
diâmetro de pistão número de cilindros
material do diafragma
Figura 32 – Exemplo completo do uso de herança
A quadro 3 mostra o conteúdo dos objetos da classe “bomba centrífuga” e da classe “tanque de teto flutuante” com suas características específicas apesar de serem ambas equipamento. Diversos atributos e operações são válidos para os dois objetos e possuem atributos e operações específicos. Quadro 3 – Conteúdo das classes Bomba de diafragma
62
Tanque de teto flutuante
Nome = P101
Nome = T111
Fabricante = Simplex
Fabricante = Simplex
Peso = 100 kg
Peso = 10.000 kg
Preço = R$ 5.000,00
Preço = R$ 50.000,00
Pressão sucção = 1,1 atm
Volume = 400.000 l
Pressão de descarga = 3,3 atm
Pressão = 1,1 atm
Taxa de fluxo = 300 l/hora
Diâmetro = 8 m
Mat. diafragma = teflon
Altura = 9 m
Modelagem de Processos Herança é um mecanismo da OO que permite criar novas classes a partir de classes já existentes, aproveitando-se das características existentes na classe a ser extendida. Este mecanismo é muito interessante, pois promove um grande reuso e reaproveitamento de código existente. Com a herança é possível criar classes derivadas (subclasses) a partir de classes bases (superclasses). As subclasses são mais especializadas do que as suas superclasses, mais genéricas. As subclasses herdam todas as características de suas superclasses, como suas variáveis e métodos. Imagine que dentro de uma organização empresarial, o sistema de RH tenha que trabalhar com os diferentes níveis hierárquicos da empresa, desde o funcionário de baixo escalão até o seu presidente. Todos são funcionários da empresa, porém cada um com um cargo diferente. Mesmo a secretária, o pessoal da limpeza, o diretor e o presidente possuem um número de identificação, além de salário e outras características em comum. Essas características em comum podem ser reunidas em um tipo de classe em comum, e cada nível da hierarquia ser tratado como um novo tipo, mas aproveitando-se dos tipos já criados, a partir da herança. Os subtipos, além de herdarem todas as características de seus supertipos, também podem adicionar mais características, seja na forma de variáveis e/ou métodos adicionais, bem como reescrever métodos já existentes na superclasse (polimorfismo). A herança permite vários níveis na hierarquia de classes, podendo criar tantos subtipos quanto necessário, até se chegar no nível de especialização desejado. Podemos tratar subtipos como se fossem seus supertipos, por exemplo, o sistema de RH pode tratar uma instância de presidente como se fosse um objeto do tipo funcionário, em determinada funcionalidade. Porém, não é possível tratar um supertipo como se fosse um subtipo, a não ser que o objeto em questão seja realmente do subtipo desejado e a linguagem suporte este tipo de tratamento, seja por meio de conversão de tipos ou outro mecanismo. Fonte: . Acesso em: 15 jun. 2012.
4.8 Conceitos avançados envolvendo classes
4.8.1 Herança múltipla Herança múltipla é uma extensão da análise orientada a objetos que permite uma classe ter mais de uma superclasse e herdar todas as características (atributos e operações) de todos os seus pais. É considerada a mais complicada forma de generalização, e nem todas as linguagens de programação dão suporte diretamente. A figura 33 mostra um exemplo de herança múltipla. 63
Unidade II Janela
Texto
Árvore
Tela
Figura 33 – Herança múltipla
Com a herança múltipla a classe tela herda todas as caracerísticas de suas três classes-pai ou superclasses. A classe janela possui as propriedades das janelas e as operações para mostrá-las e movimentá-las pela tela. A classe texto oferece as propriedades textuais das janelas, com operações/métodos para manipular linhas de texto etc. A herança múltipla aumenta o potencial de uma linguagem orientada a objetos, mas a um custo na complexidade da programação, bem como um overhead de compilação e de tempo de execução. Uma classe com mais de uma superclasse é chamada de classe-de-junção. Veículo
Terrestre
Carro
Aquático
Anfíbio
Barco
Figura 34 – Classe-de-junção anfíbia
Uma característica proveniente da mesma classe ancestral encontrada em mais de um caminho é herdada apenas uma vez. No exemplo da figura 34, a característica “cor” da classe veículo é herdada tanto por veículo terrestre como por veículo aquático, mas a subclasse veículo anfíbio, que possui herança múltipla, herda a característica “cor” de apenas uma das suas superclasses. 64
Modelagem de Processos As subclasses provenientes de generalizações podem ou não ser disjuntas. No exemplo da figura 34, as classes terrestre e aquático não são disjuntas nesse nível, porque elas se sobrepõem, isto é, algum veículo pode andar na terra e na água. 4.8.2 Classes abstratas Uma classe abstrata é uma classe que não possui instâncias diretamente, mas cujos descendentes possuem instâncias diretas. Esse tipo de classe é útil durante um projeto OO, para facilitar a programação e a manutenção dos sistemas. Às vezes, é útil criar superclasses abstratas para encapsular classes que participam em uma mesma associação. Algumas classes abstratas aparecem naturalmente no domínio da aplicação, outras são artificialmente criadas como um mecanismo para permitir reuso de código. As classes abstratas são usadas frequentemente para definir métodos para serem abordados por subclasses. Uma classe abstrata não é uma classe concreta já que não pode ser instanciada diretamente. Para ser instanciável a classe abstrata deve possuir descendentes concretos. Já uma classe concreta pode ser uma classe de folhas (último nível da hierarquia). Uma classe abstrata não pode ser classe de folha já que precisa de descendentes para ser instanciável. A figura 35 mostra uma hierarquia de classes concretas e dessa forma todas podem ser instanciáveis diretamente. Trabalhador {incompleto}
Pedreiro
Cobrador
Açougueiro
Figura 35 – hierarquia de classes concretas
A classe trabalhador também pode ser classe concreta, pois algumas ocupações podem estar contidas nelas. Dessa forma, a hierarquia é {incompleto}. Todavia, uma classe concreta pode ser refinada em várias subclasses concretas e se tornar abstrata. Quando isso acontece, a hierarquia passa a ser {completo}. O exemplo da figura 36 mostra uma superclasse empregado que se tornou abstrata no momento em que foram criadas diversas subclasses concretas, que herdaram a operação Calcular_Salario( ) e que serão programadas com lógicas específicas. 65
Unidade II
Trabalhador
{completo} Horista Calcular_Salário ()
Mensalista Calcular_Salário( )
Autônomo Calcular_Salário()
Figura 36 – Exemplo de classe abstrata
Nesse exemplo, a classe empregado não possui instâncias diretas, e a operação Calcular_Salario( ) será implementada por métodos diferentes em cada subclasse. A classe de origem de qualquer estrutura é a classe definidora de mais alto nível. Ela define o “protocolo” ou “assinatura” da estrutura (tipo de um atributo, número e tipo de argumentos e tipo de resultado de uma operação). As classes descendentes podem refinar o protocolo, restringindo os tipos ou refazendo a inicialização ou a codificação do método, mas não podem ampliar ou modificar o protocolo. Por exemplo: se um atributo foi definido na classe de origem, as classes descendentes podem restringir os valores que aceitam no atributo, mas não podem modificar seu tipo. O discriminador {completo} indica que qualquer instância da superclasse empregado será uma instância de um dos seus filhos, e a superclasse se torna abstrata. Já o discriminador {incompleto} indica que o conjunto pode esperar novas subclasses, e a superclasse é concreta. Dessa forma, a superclasse pode ser instanciada diretamente. 4.8.3 Polimorfismo (ocultamento de informações) O polimorfismo implica que uma mesma operação pode comportar-se de maneira diferente em classes distintas, apesar de possuir o mesmo nome. É a propriedade de se utilizar um mesmo nome para fazer coisas diferentes. Observação Por exemplo: mandar alguém correr. Se a pessoa estiver parada, irá sair correndo. Se a pessoa estiver no volante de um carro, irá aumentar a pressão do pé no acelerador. O polimorfismo é estimulado pelo paradigma da hereditariedade, exclusivo da OO. Dentro do polimorfismo, pode-se ter a sobreposição, a redefinição (overriding) de método: o método deve ter a mesma assinatura (nome, argumentos e valor de retorno) e código diferente. 66
Modelagem de Processos Já na sobrecarga (overloading), usa-se o mesmo nome e mais alguma característica para se fazer a mesma coisa. Dependendo dos argumentos da chamada, será chamado o método adequado. 4.8.4 Interfaces tipos e papéis A herança múltipla não é permitida em algumas de programação OO diretamente. Para facilitar a necessidade do uso desse tipo de herança, aparece o uso da interface. Uma interface, por exemplo, na linguagem Java não é uma classe, é um arquivo que define valores constantes, e as operações que outra classe deve implementar. Ela não tem operações/métodos, apenas seus protótipos. Dessa forma, quando uma classe expõe apenas constantes e operações sem implementação, também é chamada de interface. 4.8.5 Pacotes lógicos A UML define um diagrama de pacotes como sendo um modelo que descreve como os elementos são organizados dentro de pacotes e suas dependências. Um pacote pode estar contido em outros pacotes. Em um diagrama de pacotes, esses são ligados por setas pontilhadas, que têm seu estereótipo alterado de acordo com a necessidade. Um pacote pode ter qualquer diagrama da UML, porém são mais comuns em diagrama de casos de uso, para ajudar a abstração do domínio do problema, e em classes, para ajudar na organização das classes construídas em sistemas médios e grandes. Uma classe também pode ser declarada com “em pacote” e, dessa forma, terá a sua visibilidade restrita ao pacote em que reside. Classes fora desse pacote não poderão sequer saber de sua existência e, por isso, não poderá acessar classes do pacote. Uma classe dentro de um pacote sem visibilidade definida assume a visibilidade padrão do pacote. Existe uma notação especial na UML para designar um pacote. Essa notação não deixa dúvidas ao implementador que está usando o diagrama sobre a intenção do uso do pacote. pktLogin
Figura 37 – Exemplo de um pacote
67
Unidade II Nesse exemplo, todas as classes referentes ao login estão contidas nesse pacote. O acesso a essas classes internas vai depender da visibilidade do pacote. 4.8.6 Objetivos do diagrama de classes 1. Mostrar a estrutura estática do sistema. 2. Montar essa estrutura com as classes de objetos e também como seus relacionamentos. 3. Mapear os objetos a partir das classe de objetos com seus nomes, atributos e operações. 4. Aplicar as propriedades e características da tecnologia OO por meio dos mecanismos de associação, herança, polimorfismo e abstração. 4.9 Estudo de caso aplicando modelo de classes
Para demonstração do uso de um dos mais importantes modelos da UML, será utilizada a descrição de um sistema de vendas simples, com algumas funcionalidades fundamentais. Como ferramenta de apoio à preparação do estudo de caso, foi utilizada a ferramenta Case Enterprise Architect (EA).
Saiba mais O estudo de caso foi adaptado do exemplo apresentado no livro Modelagem de Objetos, do autor José Davi Furlan, publicado pela editora Makron Books (FURLAN, 1998). 4.9.1 Descrição do sistema O sistema de vendas tem o objetivo de fornecer informações unificadas, abrangentes e atualizadas aos vendedores, incluindo a situação dos pedidos tirados, a posição de crédito dos clientes, a programação de apresentação de produtos e a eficiência de vendas. A força de vendas está estruturada em filiais, zonas e setores. Uma filial atua em uma área geográfica. Os vendedores das filiais atuam em zonas de vendas e um deles é o responsável pela tal. A estrutura de visitas aos clientes pelos vendedores é definida por essas zonas de vendas e distribuída aos vendedores. As visitas ainda são organizadas semanalmente e representam períodos semanais, quinzenais e mensais. A partir da data e do período de visita, o sistema encarrega-se de gerar automaticamente o roteiro diário que deve ser seguido pelo vendedor para cumprir sua programação de vendas. 68
Modelagem de Processos 4.9.2 Requisitos do sistema A partir da descrição do sistema existem diversas alternativas de solução. De qualquer maneira, os requisitos independem de outra solução específica, mais simples ou mais complexa, já que eles mapeiam as necessidades dos clientes em forma de sentenças. A figura 38 apresenta o diagrama de requisitos do sistema a ser modelado. Observação Os requisitos são organizados em dois grupos ou pacotes. O pacote de requisitos funcionais e o pacote de requisitos não funcionais: • O pacote que contém os requisitos funcionais apresentam as características que representam o comportamento das funcionalidades ou regras de negócio que o sistema deve apoiar. • O pacote de requisitos não funcionais contém os requisitos condicionantes e níveis de desempenho que o sistema deve atender. Por exemplo: tempo de resposta do sistema, transações de segurança etc. No nosso estudo, somente serão abordados os requisitos funcionais. req Modelo de requisitos
Requisitos funcionais RF01 – O sistema deve manter atualizada a posição do cliente RF02 – O sistema deve elaborar o roteiro de visita do dia RF03 – Sistema emite informações adicionais sobre os clientes RF04 – Gera informações sobre filial RF05 – Analisa situação financeira do cliente RF06 – Análise do histórico de vendas RF07 – Registra pedido de venda
Figura 38 – Requisitos do sistema modelado na ferramenta EA
69
Unidade II 4.9.3 Modelo de classe do sistema Após uma análise dos requisitos e reuniões com a área de vendas, o analista de sistemas aprova o modelo de requisitos e detalha as funcionalidades usando o modelo de casos de uso. A partir dos cenários e das funcionalidades, são descobertas as entidades envolvidas com o problema e que serão usuárias do sistema, e as entidades de dados que serão modeladas e colocadas no banco de dados desse. As principais classes obtidas com essa análise são: 1. filial de venda; 2. zona de venda; 3. setor de venda; 4. cliente; 5. produto; 6. produto em cliente; 7. preço do produto; 8. pedido; 9. item de pedido; 10. nota fiscal; 11. fatura. A figura 39 apresenta o diagrama de classes proposto para o sistema, contendo os principais atributos. Esse modelo/diagrama é denominado de modelo de domínio, já que não contém as classes de objetos da solução tecnológica do sistema, tais como: classes de interface, classes de comunicação, classes de padrões e classes de banco de dados. Essas classes completarão o modelo de domínio na fase de design do projeto.
70
Modelagem de Processos class Diagrama de Classes
Cliente
Filial de venda - numero: int - nome: char
* Zona de venda
- codigo: int - nomeCompleto: char - nomeReduzido: char - endereco: char - IRPJ: char 1 - telefone: char - horarioDeVisita: int - CondicaoDePagamento: int - dataDaUltimaVisita: date 1
- numero: int - nomeDoVendedor: char
*
- numero: int - data: date - situacao: int - tipoDePedido: int
0..*
1
0..*
0..* Item de pedido
1
0..*
Nota fiscal - numero: int - numero: int - quantidade: date - dataDeEmissao: date - precoNegociado: int 0..* 0..* - situacao: boolean - situacao: int - condicaoDeEntrega: int 0..* 0..*
0..*
Setor de venda - nome: char - dataDaUltimaVisita: date - periodoDeVisita: date
Pedido
Produto em cliente - data: date - quantidade: int - tipo: int
0..*
1
0..*
Produto
Fatura
- codigo: int - descricao: int - faixaDePreco: int - valorUnitario: int
- numero: int - dataDeEmissao: date - dataDeVencimento: date - valor: int - dataEfetivaPagamento: date
Figura 39 – Diagrama de classes preliminar
Nesse diagrama, temos as principais classes juntamente com seus relacionamentos. O modelo, nesse momento, ainda não sofreu quaisquer questionamentos conceituais profundos, ou mesmo foi promovida uma normalização visando à sua estabilidade e integridade. As operações dessas classes são obtidas a partir do estudo das funcionalidades descritas nos modelos de caso de uso e diagramas de sequência das transações necessárias, para que o sistema atenda aos requisitos, que não serão mostrados nesse exemplo, já que se pretende apresentar somente um exemplo de aplicação do modelo de classes. A figura 40 apresenta o mesmo diagrama de classes, mas com as principais operações necessárias para resolver o sistema.
71
Unidade II class Diagrama de Classes
Cliente - codigo: int - nomeCompleto: char - nomeReduzido: char - endereco: char - IRPJ: char - telefone: char - horarioDeVisita: int - CondicaoDePagamento: int - dataDaUltimaVisita: date
Filial de venda - numero: int - nome: char
1
+ obte_Clientes_Ativos() : void + obter_Limite_Credito() : void + obter_Condicao_Entrega : void + obter_Condicao_Pagamento() : void + obter_dia_Entrega() : void
+ obter_Nome_Filial(): void
- numero: int 0..* - data: date - situacao: int - tipoDePedido: int + obter_Pedido() : void + incluir_Pedido() : void
1
1
1
*
0..*
Zona de venda - numero: int - nomeDoVendedor: char
*
Pedido
0..*
0..*
Item de pedido - numero: int - quantidade: date - precoNegociado: int - situacao: int - condicaoDeEntrega: int
0..*
Nota fiscal - numero: int - dataDeEmissao: date 0..* 0..* - situacao: boolean + obter_NF_Cliente() : void
+ obter_Descricao_Produto() : void + obter_Preco_Produto() : void
Setor de venda
0..*
0..*
- nome: char - dataDaUltimaVisita: date - periodoDeVisita: date
0..* 0..*
+ atualizar_Data_Ultima_Visita() : void
Produto em cliente - data: date - quantidade: int - tipo: int + registrar_Estoque_Cliente() : void + registrr_Produto_Recolhodo() : void
Fatura
1 Produto
- codigo: int - descricao: int - faixaDePreco: int - valorUnitario: int + obter_Descricao_Produto() : void + obter_Preco_Produto() : void
- numero: int - dataDeEmissao: date - dataDeVencimento: date - valor: int - dataEfetivaPagamento: date + obter_Faturas_Vencidas() : void + obter_Faturas_A_Vencer
Figura 40 – Diagrama/modelo de classes com algumas operações
O modelo de classes, quando completo, incluindo atributos e operações, pode ser implementado em um banco de dados e em uma linguagem de programação orientada a objetos. Outras classes serão necessárias, tanto para o banco de dados, como para a implementação em uma linguagem específica nas próximas fases do desenvolvimento. Para a fase de design, deverão ser desenvolvidos os modelos de interface homem versus máquina, que indicará as interações dos usuários com o sistema. Para isso deverão ser montados os modelos de casos de uso com os atores e as funcionalidades. 72
Modelagem de Processos Por meio do modelo de caso de uso e do protótipo, os diagramas de sequência indicarão as mensagens que serão trocadas entre os objetos. A partir dessas mensagens, o modelo de classe será aumentado, e todas as operações ou métodos deverão ser incluídos nas classes específicas. Resumo Esta unidade apresentou uma visão da estrutura da UML. Foi discutido que, de acordo com os autores a UML, não é um modelo de processo/ metodologia de software. Ela é considerada uma linguagem padrão de modelagem de sistemas e, por isso, tem uma notação e um mecanismo para “mostrar o problema”, de forma a expor a essência do domínio de um aplicativo. Também se detalhou os conceitos envolvidos com todos os diagramas apresentados na linguagem UML, principalmente o diagrama de classes de objetos. O detalhamento desse modelo se justifica devido à sua importância na tecnologia orientada a objetos. A partir desse modelo de classes detalhado, são derivadas as soluções de banco de dados e as classes que serão implementadas em linguagens específicas. O diagrama de classes é a entrada para os processos de arquitetura e implentação, tanto do banco de dados como do aplicativo. Uma das mensagens mais importantes é com relação ao reuso de software. Quando se trabalha com os conceitos envolvidos com o reuso de software, o modelo de classes é fundamental e apresenta os mecanismos de herança e polimorfismo que permite um avanço considerável em direção à reusabilidade. Exercícios Questão 1. De acordo com a IBM-Rational, a Unified Modeling Language (UML) é uma linguagem de modelagem não proprietária adotada pela OMG, e não uma metodologia de desenvolvimento. Ela não diz como desenvolver ou manter um sistema ou software, mas auxilia a visualizar seu desenho e a comunicação entre os objetos envolvidos com o sistema. Também permite que desenvolvedores vejam os produtos de seus trabalhos em diagramas ou gráficos padronizados, oferecendo uma notação gráfica, especificando os significados, isto é, ela é uma liguagem com uma semântica predefinida. É uma notação independente de metodologias ou processos, embora muitas delas, como o RUP (Rational Unified Process), tenham sido especificamente desenvolvidos utilizando a UML. Outro fator importante é a diferença entre um modelo UML e um diagrama (ou conjunto de diagramas) de UML; um diagrama ou gráfico é uma representação gráfica da informação de um determinado sistema, e o modelo pode 73
Unidade II existir independentemente. Considerando-se os conceitos sobre a UML, analise as afirmações a seguir e assinale a alternativa incorreta: A) A visão de caso de uso de um sistema descreve as fucionalidades ou o comportamento do sistema assim como os analistas e programadores de sistemas. B) De acordo com diversos autores, o diagrama de classes de objetos é o mais importante dos diagramas da UML, pois uma classe de objetos é uma coleção de objetos que podem ser descritos com os mesmos atributos e as mesmas operações. Também representam as entidades envolvidas em um sistema de informação. C) Para que um sistema seja executado, as classes de objetos precisam estar relacionadas ou associadas no modelo de classes. Esse relacionamento ou associação deve estar de acordo com as necessidades do sistema e deve cobrir as regras de negócio envolvidas com as funcionalidades que o sistema executará. D) Sistema é a representação abstrata do mundo real; quanto mais complexo, mais necessita de descrições de seus vários aspectos. Ele deve mostrar: a estrutura estática dos objetos e a interação dinâmica entre eles; as características do tipo de tempo de processamento, de confiabilidade, de usabilidade etc.; e, por último, o mapeamento do modelo organizacional em termos da organização do trabalho, mapeamento e os códigos. E) Herança é o mecanismo de reutilização de atributos e operações definidos em superclasses por classes mais específicas, podendo ser usada para expressar tanto generalização como associação. Resposta: Alternativa A. De acordo com a OMG, a UML apresenta 4 grandes objetivos: especificação de um sistema, documentação de todos os artefatos produzidos no processo, estruturação para subvisualização e maior visão lógica do desenvolvimento completo de um sistema de informação. A UML é uma linguagem padronizada de se modelar sistemas de informação desenvolvidos na tecnologia da Orientação a Objetos. Análise das alternativas A) Incorreta. A visão de caso de uso de um sistema realmente descreve as funcionalidades ou o comportamento de um sistema, mas tem como princípio fundamental entender os requisitos do sistema e interpretá-los graficamente. Outro fator fundamental é que os Casos de Uso são como uma linguagem de comunicação entre os usuários e os desenvolvedores de um determinado sistema. B) Correta. Uma classe de objetos representa uma ideia ou um conceito simples e categoriza objetos que possuem propriedades similares, configurando-se em um modelo para a criação de novas instâncias. Exemplo: uma classe que represente um Cliente pode ser instanciada para representar 74
Modelagem de Processos um cliente pessoa física ou um cliente pessoa jurídica, os quais possuem características semelhantes e específicas. C) Correta. Esses relacionamentos ou associações definem as regras que são impostas pelas regras de negócio da aplicação sendo modelada. D) Correta. Cada visão apresentada em um diagrama da UML é descrita por um ou mais diagramas, que contêm informações referentes a um aspecto específico do sistema sendo modelado. E) Correta. Quando se usa o paradigma da herança na OO, uma classe de menor nível (subclasse) é considerada uma classe especializada ou uma classe de extensão da classe de maior nível (superclasse). Questão 2. Dentro da UML, o diagrama de classe de objetos tem por objetivo descrever um grupo de objetos com propriedades similares, relacionamentos comuns com outros objetos e uma semântica comum. As propriedades são: os atributos e as operações. Estas são encapsuladas no objeto. Exemplo: em um sistema ERP, o cliente e o fornecedor são classes de objetos. Cada cliente tem um nome e um endereço; estes seriam os atributos comuns da classe cliente. Fornecedores também podem ter os mesmos atributos, nomes e endereços definidos. Entretanto, elas podem não estar definidas em uma mesma estrutura de objetos devido à distinção semântica. Como se pode observar, o agrupamento em classes não leva em conta apenas o compartilhamento de propriedades, senão essas classes deveriam ser sempre agrupadas na mesma estrutura. Considerando-se os conceitos apresentados sobre a UML nesta unidade, examine as afirmações a seguir e assinale a alternativa incorreta: A) Com a hierarquia de classes de objetos que são apresentadas no diagrama de classes e com o mecanismo de herança, o modelo de classes de objetos potencializa o reuso no desenvolvimento de software OO. B) Para se ter herança múltipla em um modelo de classes, necessita-se que uma subclasse herde atributos e operações de mais de uma superclasse. C) Quando um modelo de classes apresenta herança múltipla e vai ser implementado em uma linguagem de programação OO e em banco de dados, pode-se ter problemas na transição, devido a que esses ambientes podem não suportar a herança múltipla. D) O uso de herança múltipla deve ser evitado a todo custo nos projetos de sistema OO, haja visto ele nunca aparecer na modelagem do mundo real. E) Uma classe abstrata possui a mesma estrutura de uma classe concreta, a única diferença é que tem um modificador abstract em sua definição de atributo ou de operação. Ela não pode ser instanciada, ou seja, não é possível obter objetos. Classes abstratas podem ser herdadas por outras classes abstratas ou concretas, e isso possibilita o polimorfismo. Resolução desta questão na plataforma. 75
MODELAGEM DE PROCESSOS UNIDADE II Questão 2 Resposta correta: alternativa D. Justificativa: todo objeto sabe a que classe ele pertence, ou seja, a classe de um objeto é um atributo implícito do objeto. Este conceito é suportado na maior parte das linguagens de programação orientada a objetos, como C ++, ADA etc. A) Correta. Como várias subclasses podem herdar as propriedades de uma superclasse, os mesmos atributos e operações são reutilizados nas subclasses, levando ao reúso de software. B) Correta. A herança múltipla permite que uma subclasse herde propriedades de várias superclasses. Exemplo: carro e barco são objetos que possuem características semelhantes, mas diferentes comportamentos. Todavia, um anfíbio pode se comportar como um carro quando em terra e como um barco quando está na água. Então, esse animal pode herdar tanto propriedades e comportamentos de carro como do barco. C) Correta. Exemplo: na linguagem de programação Java, não temos a implementação da herança múltipla, e isso dificulta a transição do modelo de classes para o código na linguagem Java. D) Incorreta. O uso de herança múltipla, apesar de não ser comum nos modelos de sistemas OO, aparece na modelagem do mundo real, porém raramente é implementada em linguagens de programação. E) Correta. As classes abstratas são permissões das linguagens orientadas a objeto que permitem definir classes com a mesma estrutura de classes concretas. Podem ser herdadas por subclasses que programam as operações com a mesma assinatura herdada, mas com códigos específicos, por meio do mecanismo do polimorfismo.
Unidade III
Unidade III 5 MODELAGEM COMPORTAMENTAL (MODELO DINÂMICO) 5.1 Introdução
Na abordagem de análise da UML, a visão de modelo comportamental representa o sistema do ponto de vista dos comportamentos e interações do sistema com o usuário. Os diagramas que modelam o comportamento de um sistema da UML são: • diagrama de caso de uso (use case): é um diagrama de uso geral para as fases de levantamento e análise de requisitos do sistema; • o diagrama de estados ou máquina de estados: que procura acompanhar as mudanças sofridas por um objeto dentro de um processo no tempo; • o diagrama de atividades: que descreve os passos a serem percorridos para a conclusão de uma atividade. • os diagramas de interação: que são dividios em: — diagrama de sequência: diagrama que descreve a ordem temporal em que as mensagens são trocadas entre os objetos; — diagrama geral interação: é uma variação dos diagramas de atividades que fornece visão geral dentro do sistema ou processo do negócio; — diagrama de comunicação: associado ao diagrama de sequência, complementando-o e concentrando-se em como os objetos estão vinculados. — diagrama de tempo: diagrama que descreve a mudança de estado ou condição de uma instância de uma classe, ou seu papel durante o tempo. Esta unidade abordará os principais diagramas comportamentais da UML. Lembrete A UML propõe 13 diagramas que cobrem as estruturas estáticas e os comportamentos de um aplicativo ou sistema de software. Nesta unidade, somente serão abordados os diagramas denominados comportamentais. 76
Modelagem de Processos 5.2 Modelo de casos de uso
O caso de uso nos modelos da UML é um elemento que descreve como um usuário do sistema proposto interage com o sistema para realizar uma determinada tarefa discreta. Ele descreve e significa uma interação simples, a todo o tempo, que tenha significado para o usuário (uma pessoa, uma máquina ou outro sistema). Um caso de uso, de acordo com a UML: • tipicamente, tem requisitos e restrições que descrevem as facilidades e regras sobre as quais ele opera; • pode ter um diagrama associado (diagrama de sequência ou de atividades) que ilustre seus comportamentos ao longo do tempo: quem faz o quê, para quem e quando. • tipicamente, tem cenários associados com ele e que descrevem o fluxo de trabalho durante todo o tempo que realiza suas tarefas, até produzir os resultados finais. • a especificação da OMG UML afirma: “um caso de uso é um tipo de classificador de comportamento que representa uma declaração de um comportamento oferecido”.1 Cada caso de uso especifica alguns comportamentos, possivelmente incluindo variantes, as quais pode executar em colaboração com um ou mais atores. Lembrete Os elementos de casos de uso são utilizados para construir modelos de caso de uso. Eles descrevem a funcionalidade do sistema a ser construído, os requisitos, as restrições e como o usuário interage com o sistema. Muitas vezes, os diagramas de sequência são associados com casos de uso para capturar o fluxo de trabalho e o comportamento do sistema. 5.2.1 Diagramas de caso de uso O diagrama ou modelo de casos de uso mostra o que existe fora do sistema (atores) e o que pode ou deve ser executado pelo sistema (casos de uso). Os casos de uso são importantes, pois provêm uma ferramenta para capturar os requisitos do sistema, ou seja, o que o sistema necessita disponibilizar para possibilitar a execução das atividades do negócio. 1
UML Superestrutura Especificação, versão 2.1.1, p. 592.
77
Unidade III O conjunto de casos de uso do sistema representa a funcionalidade desse, isto é, a totalidade de maneiras de se utilizar o sistema. Um diagrama de caso de uso é um gráfico de: • atores; • conjunto de casos de uso do sistema, encapsulados pela fronteira desse; • a associação entre os atores e os casos de uso utilizados por eles; e • os eventuais relacionamentos entre os próprios casos de uso. A figura 41 mostra um exemplo de um diagrama típico de casos de uso. uc Use Case Model
Faz login
Usuário
<> Registra Usuário
Figura 41 – Diagrama ou modelo de casos de uso
5.2.1.1 Atores Os atores representam toda a necessidade de troca de informação com o sistema. Eles constituem, portanto, o ambiente do sistema (seres humanos, máquinas, agrupamentos lógicos, outros sistemas). A diferença entre atores e usuários é que um ator representa certa regra que um usuário pode utilizar na interação com o sistema, e o usuário é a pessoa que está usando aquela regra, naquele momento. Dentro da tecnologia OO, o ator é uma classe, enquanto o usuário é uma instância daquela classe. A instância existe apenas enquanto o usuário está fazendo algo no sistema, portanto, o mesmo usuário pode ser instância de vários atores no sistema. 78
Modelagem de Processos A figura 42 mostra a notação de Ator na UML.
Cliente Figura 42 – Notação de ator
O ícone padrão do estereótipo do ator é a figura do stick man. O nome do ator deve ser sempre um substantivo no singular, por exemplo: cliente, professor, operador etc. Observação A especificação da OMG UML2 afirma: Um ator modela um tipo de papel desempenhado por uma entidade que interage com o sistema (por exemplo, intercâmbio de dados e sinais), mas que é externo ao sistema. Atores podem representar papéis desempenhados por usuários humanos, de hardware externo ou de outros sistemas. Note que um ator não representa, necessariamente, uma entidade física específica, mas apenas uma faceta particular (isto é, “papel”) de alguma entidade que é relevante para a especificação de seus casos de uso associados.
Saiba mais Vale a pena fazer download do manual da OMG Unified Modeling Language (OMG UML), o Infrastruture versão 2.3, que se encontra gratuitamente disponível em: , e possui todas as definições e características dos modelos da UML. Assim, uma única instância física pode desempenhar o papel de vários atores diferentes e, inversamente, um determinado ator pode ser jogador de várias instâncias diferentes. 5.2.2.2 Casos de uso Uma instância de um ator desencadeia a execução de um caso de uso no sistema. Na UML, um caso de uso é representado por uma elipse com seu nome em texto dentro. 2
UML Superestrutura Especificação, versão 2.1.1, p. 584.
79
Unidade III A figura 43 mostra um exemplo da notação de caso de uso na UML. Receber Pagamento Figura 43 – Notação de caso de uso
Um caso de uso é, portanto, um conjunto de transações, executadas em uma determinada sequência, em diálogo com o sistema. Além disso, um caso de uso pode ser visto como uma classe de objetos, devido ao fato de possuir propriedades e comportamentos. Quando se inicia um caso de uso, se está instanciando a classe: caso de uso. Cada instância dessa classe é chamada de cenário. Cada cenário retrata a sequência de interações entre atores (estímulos e respostas) e classes do sistema (consultas e atualizações), com todas as alternativas de decisão (e respectivas ações) definidas. Um cenário (instância de caso de uso) pode ser desencadeado: • por meio de um evento externo (estimulado por um usuário – instância de um ator); ou • por um evento temporal (o sistema toma a iniciativa a partir de um algoritmo interno – tempo transcorrido, mudança de estado etc.) Para se representar os cenários de um caso de uso, podem ser utilizados outros diagramas da UML, tais como, os diagramas de interação: diagrama de atividades, diagrama de sequência ou de comunicação. O nome do caso de uso deve ser sempre composto de um verbo e um objeto direto. O verbo pode estar no infinitivo ou na terceira pessoa do singular. O importante é manter um padrão que todos sigam na empresa, por exemplo: emitir recibo ou emite recibo. Observação O diagrama de casos de uso exerce um papel importante na análise de sistemas no momento de se entender e especificar as necessidades do cliente ou usuário, já que: • é o principal diagrama para ser usado no diálogo com o usuário na descoberta e validação de requisitos; • o diagrama pode ser construído a partir do protótipo do sistema, pois mostra os usuários (atores) interagindo com o sistema, de acordo com as telas, páginas ou relatórios apresentados no protótipo; 80
Modelagem de Processos • os casos de uso constituem elementos que estruturam todas as etapas do processo de software. 5.2.1.3 Para identificar casos de uso A partir do levantamento das necessidades do cliente ou de um usuário, a identificação dos casos de uso devem seguir um roteiro, conforme o sugerido a seguir: • O que cada ator necessita ou deve ser capaz de fazer com ou para o sistema. Um ator pode armazenar, eliminar, alterar ou ler informações. • Que tarefas devem ser executadas para suprir deficiências da atual implementação do sistema. • Quais tarefas executar que a implementação atual não supre (novas funcionalidades). 5.2.1.4 Casos de uso empregados por mais de um ator Quando vários atores do mesmo tipo utilizam o mesmo caso de uso, é possível identificar um ator abstrato e tornar os outros atores do mesmo tipo que o utilizam herdeiros dele. Ou ainda, eleger um ator como usuário do caso de uso e tornar os demais atores seus herdeiros. 5.2.1.5 Casos de uso utilizados por outros casos de uso Um relacionamento de extensão (extend) de um caso “B” (caso estendido) para um caso “A” (caso básico) indica que instâncias específicas de “A” podem incluir “B”. Portanto, um caso de uso de extensão é normalmente criado para mostrar comportamentos especiais e de exceção, que complementam o caso básico, quando aquelas condições excepcionais ocorrerem. A figura 44 mostra um caso de uso com extensão. uc Use Case Model
A
<>
B
Figura 44 – O uso da extensão
No exemplo da figura 45, somente nas instâncias do caso de uso receber pagamento em que o prazo estiver vencido é que o caso calcular juros de mora será utilizado como extensão. 81
Unidade III uc Use Case Model
Receber pagamento
<>
Calcular juros de mora
Figura 45 – Uso de extend (extensão)
Um relacionamento de inclusão (include) de um caso A para um caso B indica que uma instância do caso A incluirá, também, as instâncias do caso B. Nesse caso, o caso de uso B sempre será acionado quando o caso de uso A estiver ativo. A figura 46 mostra esse caso. uc Use Case Model
A
<>
B
Figura 46 – Uso do include
A figura 47 mostra um exemplo de include. Nesse caso, sempre que o caso de uso receber pagamento for ativado, o caso de uso emitir recibo também será acionado. uc Use Case Model
Receber pagamento
<>
Emitir recibo
Figura 47 – Uso do include (inclusão)
Para todas as instâncias do caso de uso receber pagamento, será usado o caso de uso emitir recibo. O caso de uso emitir recibo poderá ser usado também por outros casos de uso. Tanto o relacionamento de extensão (extend) como de inclusão (include) são provenientes de fatoração de casos de uso maiores, sendo que: • extensão normalmente descreve variações de um comportamento normal, e • inclusão revela comportamentos utilizados por mais que um caso de uso (reuso de caso de uso). 5.2.1.6 Especificação do modelo de caso de uso A UML não específica um formato rigído para os cabeçalhos e a estrutura de um caso de uso. Eles podem ser alterados de acordo com as necessidades de documentação dos sistemas. 82
Modelagem de Processos O quadro 4 a seguir mostra um exemplo de especificação de um caso de uso de alto nível. Quadro 4 – Descrição de um caso de uso de alto nível Caso de uso Atores envolvidos Tipo
Comprar Itens Cliente e operador Primário
Descrição
Um cliente chega ao caixa com itens para comprar. O operador registra os itens e coleta o pagamento. Ao final, o cliente sai com os itens.
O quadro 5 mostra um exemplo de um caso de uso extendido (detalhado). Quadro 5 – Caso de uso extendido Caso de uso Atores envolvidos
Comprar itens com dinheiro Cliente e operador
Propósito
Capturar uma venda e seu pagamento em dinheiro.
Descrição
Um cliente chega ao caixa com itens para comprar. O operador registra os itens e coleta um pagamento com dinheiro. Ao final, o cliente sai com os itens.
Tipo Referência
Primário e essencial . Requisitos funcionais: R1, R2, R3 (requisitos).
O quadro 6 mostra a sequência de eventos do exemplo do quadro 5. Ações dos atores e do sistema durante a ocorrência de compra. Quadro 6 – Sequência de eventos em uma compra de cliente Ação do ator
Resposta do sistema
1. Este caso de uso começa quando um cliente chega ao caixa com itens para comprar. Se há mais de um do mesmo item, o operador também pode informar a quantidade.
3. Determina o preço do item e adiciona informação sobre o item à transação de venda em andamento. Mostra a descrição e o preço do item corrente.
4. Após processar o último item, o operador indica ao sistema.
5. Calcula e mostra o valor total da venda.
2. O operador registra o identificador de cada item.
6. O operador informa o total ao cliente. 7. O cliente entrega um pagamento em dinheiro, possivelmente maior do que o valor total. 8. O operador registra o valor recebido em dinheiro. 10. O operador deposita o dinheiro e retira o troco devido. O operador entrega o troco e o recibo ao cliente.
9. Mostra o troco devido. Emite um recibo. 11. Registra a venda no log de vendas completadas.
12. O cliente sai com os itens comprados.
83
Unidade III Essa sequência de eventos ainda pode comportar os eventos de excessão ou sequência de erros. Essas sequências devem ser colocadas como caminhos alternativos e podem merecer que novos casos de uso possam ser definidos para comportá-las.
Saiba mais O autor Martin Fowler escreveu com Kendall Scott um livro denominado UML Distilled, que resume a UML e discute todos os modelos ou diagramas envolvidos com a linguagem. O livro se encontra na sua 3ª edição. Ele foi traduzido para o português pela editora Bookman em 2004, e se chama UML Essencial – Um breve guia para a linguagem padrão de modelagem de Objetos. O livro “UML Essencial’ descreve a maioria dos tipos de diagramas UML, sua utilização e a notação básica envolvida na criação. Esses diagramas incluem classes, sequência, objeto, pacote, instalação, casos de uso, máquina de estados, atividades, comunicação, estruturas compostas, componentes, visão geral da interação e diagramas de temporização. Os exemplos são claros e as explicações chegam ao fundamento lógico de projeto de software orientado a objetos. 5.2.1.7 Estudo de caso com o modelo de caso de uso Para demonstração da aplicação do modelo de caso de uso da UML, será utilizada a descrição de um sistema de vendas simples com algumas funcionalidades fundamentais (mesmo exemplo utilizado na unidade 2, como exemplo do uso do diagrama de classes). Como ferramenta de apoio à preparação do estudo de caso, foi utilizada a ferramenta Case Enterprise Architect (EA).
Saiba mais O estudo de caso foi adaptado do exemplo apresentado no livro Modelagem de objetos, do autor José Davi Furlan, publicado pela Makron Books (FURLAN, 1998). Foi um dos autores brasileiros pioneiros na divulgação da UML no Brasil.
84
Modelagem de Processos Ferramentas Case: O termo Case (Computer-Aided Software Engineering) signfica Engenharia de software auxiliada por computador. Antigamente, os engenheiros de software desenvolviam software para outras áreas, tais como, Engenharia, Arquitetura, Medicina etc., mas não se utilizavam de software para fazer seu trabalho, confirmando o velho ditado “casa de ferreiro, espeto de pau”. Com a necessidade de aumentar a produtividade e melhorar a qualidade, foram obrigados a desenvolver também software para uso próprio. Inicialmente, era utilizado o termo Workbench, que significa “bancada de trabalho” e que designava as ferramentas, geralmente automatizadas, que auxiliavam no trabalho dos desenvolvedores de software. Mais tarde, surgiu o termo Case. Uma ferramenta Case é qualquer software que auxilia as pessoas que trabalham em um ambiente de desenvolvimento de software. A presença de ferramentas Case é vital hoje em dia para o bom funcionamento desse ambiente, e elas existem apoiando todo o ciclo de desenvolvimento (análise, projeto, implementação, teste e manutenção). Há também ferramentas Case para apoiar a gerência dos projetos de desenvolvimento, a gerência de configuração e a gerência de riscos. Sem ferramentas, uma metodologia ou método não terá boa aceitação no mercado devido ao aumento de trabalho que provoca no ambiente. Isto ocorreu com diagramas, como o DFD e o E-R, que só foram amplamente utilizados quando surgiram as primeiras ferramentas para auxiliar na tarefa de diagramação. Hoje em dia, há também a difusão do termo I-Case, que é usado para caracterizar um grupo de ferramentas Case integradas, isto é, que se relacionam entre si (entradas e saídas) e que permitem controlar a consistência dos dados quando uma metodologia é seguida. Vantagens das ferramentas Case: • Maior qualidade dos produtos finais: as ferramentas Case diminuem a probabilidade de erros, uma vez que podem ajudar no controle de consistência dos dados em um ambiente de desenvolvimento de software; também proporcionam maior eficácia dos produtos, ao auxiliarem as fases de análise e teste do produto pelo usuário. • Produtividade: ao ajudar na realização de tarefas e até mesmo ao realizar algumas automaticamente, as ferramentas contribuem para uma maior agilidade no desenvolvimento de software, isto é, mais produtos em menos tempo. 85
Unidade III • Eliminação de trabalho monótono: as ferramentas Case podem realizar algumas tarefas cansativas para os desenvolvedores, tais como, procurar informações e desenhar símbolos de um diagrama, as quais são mais suscetíveis ao erro. • Mais tempo para a tomada de decisão: em consequência das ferramentas realizarem certas atividades pelas pessoas, essas ficam liberadas para outras tarefas, geralmente mais nobres, que exigem tomada de decisão e criatividade, ao invés de tarefas repetitivas. • Flexibilidade para mudanças: as ferramentas permitem que sejam mudados dados e diagramas de maneira mais rápida e fácil, o que ajuda o desenvolvedor no trabalho de atender às necessidades do usuário. • Menos programação: as ferramentas eliminam muito do trabalho de programação, deixando mais tempo para que a equipe técnica se preocupe com a análise do sistema, que é onde se define como solucionar o problema do usuário. • Melhor documentação: por armazenarem dados e diagramas, as ferramentas também contribuem para uma melhor documentação do sistema, agilizando relatórios, busca de informações e alterações. • Manutenção mais fácil e ágil: por consequência do item anterior, é possível ter mais informações sobre o software na hora de realizar sua manutenção (correção, atualização ou expansão). 5.2.1.8 Descrição do sistema – exemplo de uso do modelo de caso de uso O sistema de vendas tem o objetivo de fornecer informações unificadas, abrangentes e atualizadas aos vendedores, incluindo a situação dos pedidos tirados, posição de crédito dos clientes, a programação de apresentação de produtos e a eficiência de vendas. A força de vendas está estruturada em filiais, zonas e setores. Uma filial atua em uma área geográfica. Os vendedores das filiais atuam em zonas de vendas, e um deles é o responsável pela zona de vendas. A estrutura de visitas aos clientes pelos vendedores é definida por zona de vendas e distribuída aos vendedores. As visitas ainda são organizadas semanalmente e representam períodos semanais, quinzenais e mensais. A partir da data e do período de visita, o sistema encarrega-se de gerar automaticamente o roteiro diário que deve ser seguido pelo vendedor para cumprir sua programação de vendas. 5.2.1.8.1 Requisitos do sistema A partir da descrição do sistema, existem diversas alternativas de solução. De qualquer maneira, os requisitos independem de outra solução específica, mais simples ou mais complexa, já que eles mapeiam as necessidades dos clientes em forma de sentenças. 86
Modelagem de Processos A figura 48 apresenta o diagrama de requisitos do sistema a ser modelado. Os requisitos são organizados em dois grupos ou pacotes. O pacote de requisitos funcionais e o pacote de requisitos não funcionais: • O pacote que contém os requisitos funcionais apresenta as características que representam o comportamento das funcionalidades ou regras de negócio que o sistema deve apoiar. • O pacote de requisitos não funcionais contém os requisitos condicionantes e níveis de desempenho que o sistema deve atender. Por exemplo: tempo de resposta do sistema, transações de segurança etc. No nosso estudo, somente serão abordados os requisitos funcionais. Ler foneticamente. req Modelo de requisitos
Requisitos funcionais RF01 – O sistema deve manter atualizada a posição do cliente RF02 – O sistema deve elaborar o roteiro de visita do dia RF03 – Sistema emite informações adicionais sobre os clientes RF04 – Gera informações sobre filial RF05 – Analisa situação financeira do cliente RF06 – Análise do histórico de vendas RF07 – Registra pedido de venda
Figura 48 – Requisitos do sistema modelado na ferramenta EA
5.2.1.7.2 Modelo de caso de uso do sistema O primeiro passo para modelar o sistema é a partir dos requisitos apresentados na figura 48, que definem os casos de uso que descrevem o que o sistema de suporte a vendas irá oferecer em termos de funcionalidades. Os atores envolvidos são pessoas, o vendedor e o comprador. O vendedor interage com o sistema no sentido de obter e registrar o pedido do comprador. O comprador recebe uma série de informações do sistema, mas não interage com o sistema diretamente para entrada de dados ou para consultas online. 87
Unidade III A figura 49 apresenta uma possível visão de solução para o sistema. O diagrama ou modelo de caso de uso não mostra as soluções de arquitetura do sistema, mostra apenas os atores interagindo com as funcionalidades dele. uc Modelo de Caso de Uso
Manter cliente
Mostra detalhes do cliente <>
Elabora o roteiro de visita
Informa visita <>
Coloca pedido
Vendedor Manter filial
Gera informações sobre filial
Cliente
<> <> Analisa situação Analisa financeira histórico de vendas
Figura 49 – Modelo de caso de uso do estudo de caso
5.2.1.8.3 Especificações do modelo de caso de uso Inicialmente, deve-se descrever os atores envolvidos com o sistema e suas interações. Ator vendedor: • O vendedor, com base na zona e setor de vendas da filial, solicita a elaboração do roteiro de visita a clientes do dia. • O vendedor, a partir do roteiro de visitas, programa seu deslocamento a clientes. • O sistema deverá estar preparado para informar o vendedor sobre a localização dos logradouros e as principais alternativas viárias de acesso ao cliente. • O sistema deve estar preparado para fornecer informações adicionais sobre os clientes para apoiar o vendedor na venda. • O vendedor acessa o sistema para obter dados gerais sobre a filial. 88
Modelagem de Processos • O vendedor analisa e discute com o cliente a situação da fatura com o cliente, tanto as faturas vencidas, como as faturas a vencer nos próximos períodos. • O sistema permite que o vendedor analise a média de vendas por produto nos últimos meses, por meio do histórico de vendas ao cliente. • Após a formalização do pedido de venda, o vendedor faz as últimas anotações sobre a visita ao cliente. Ator cliente: • O ator cliente ou comprador recebe, do sistema, dados sobre seu cadastro e um aviso da visita do vendedor com data e hora prevista. Ele também recebe uma cópia do pedido depois de dada a entrada pelo vendedor. • Após as descrições dos atores e de suas interações com o sistema, o desenvolvedor deverá descrever os casos de uso, usando padrão definido pela organização em que trabalha. • Será mostrada, como exemplo, a descrição do caso de uso manter filial, que é de responsabilidade do vendedor. A ferramenta Case utilizada é o EA. • Descrição geral: — A força de vendas está estruturada em filiais, zonas e setores. Uma filial atua em uma área geográfica. Os vendedores das filiais atuam em zonas de vendas e um deles é o responsável pela zona de vendas. • Pré-condições: vendedor autorizado no sistema. • Pós-condições: filial liberada para uso. • Caminho básico: — Nome: inclui filial. — Descrição (passos): 1. Vendedor responsável entra com dados da Filial. 2. Sistema valida filial. 3. Vendedor responsável entra com dados da zona de venda. 4. Sistema valida zona de venda. 89
Unidade III 5. Sistema associa zona de venda à filial. 6. Vendedor responsável entra com dados do setor de vendas. 7. Sistema valida setor de vendas. 8. Vendedor responsável associa setor de vendas à zona de venda. 9. Vendedor responsável associa outros vendedores à zona de vendas. • Caminho alternativo: — Nome: altera filial. — Descrição (passos): 1. Vendedor responsável entra com filial. 2. Sistema valida filial. 3. Vendedor altera dados da filial. 4. Sistema altera dados da filial. 5. Vendedor responsável entra com dados da zona de venda/ setor de vendas a serem alterados. 6. Sistema valida zona de venda/setor de vendas. 7. Sistema altera dados da zona ou setor de vendas. 8. Vendedor associa/disassocia zona de venda a filial. 9. Sistema altera dados no banco de dados. • Caminho alternativo: — Nome: exclui filial. — Descrição (passos): 1. Vendedor responsável entra com filial/zona de venda ou setor de vendas que quer excluir. 2. Sistema valida filial/zona e setor de vendas. 90
Modelagem de Processos 3. Sistema verifica se existe cliente com pedido pendente. 4. Sistema exclui vendedores da lista da filial. 5. Sistema elimina filial/zona ou setor de vendas. • Caminho alternativo: — Nome: erros. — Descrição (passos): 1. Filial/zona ou setor de vendas inválido. 2. Filial/zona ou setor de vendas já existe. 3. Filial/zona ou setor de vendas não existe. 4. Não é possível eliminar filial/zona ou setor de vendas. 6 Outros modelos comportamentais da UML 6.1 Introdução
A UML apresenta diversos tipos de diagramas que modelam o comportamento de um sistema. Entre os diversos diagramas ou modelos comportamentais, o diagrama de caso de uso é considerado o mais importante deles e tem como finalidade modelar as necessidades ou requisitos de um cliente ou usuário de um sistema. Todavia, outras necessidades de representar a realidade surgem quando os analistas de sistemas estão desenvolvendo ou especificando todas as abordagens necessárias para um entendimento completo do sistema que está sendo construído. Para dar apoio aos desenvolvedores com relação ao comportamento do sistema perante uma determinada realidade ou situação, a UML propõe diversas alternativas de modelos que devem ser utilizados de acordo com as características do sistema ou do tipo de aplicação necessária para automatizar um determinado processo de negócio. Os modelos comportamentais, além do modelo de caso de uso, são: diagrama de atividades, diagrama de estados ou máquina de estados. Outro diagrama importante abordado nesta unidade é o diagrama de sequência, sendo que os diagramas de comunicação e de tempo não serão detalhados por não serem os mais utilizados na prática da UML.
91
Unidade III 6.2 Diagrama de atividades
Um diagrama de atividade é um fluxo que representa as passagens de uma atividade para outra durante um fluxo de trabalho. Seu propósito é estudar os fluxos dirigidos por processamento interno, descrevendo as atividades em uma operação. Esse diagrama tem sido usado para desenhar as lógicas dos cenários dos casos de uso, ou a lógica de processamento de uma operação de uma classe de objetos mais complexa. A notação de um diagrama de atividades da UML usa os seguintes símbolos: Quadro 7 – Símbolos do diagrama de atividade Símbolos Atividade
Breve descrição Representa uma atividade realizada por um usuário ou pelo sistema. Representa a passagem de uma atividade para outra. Esta passagem também é chamada de gatilho (trigger). É também chamado de fluxo de controle. Símbolo de decisão. Podem-se apontar diversas entradas ou saídas para esse símbolo de decisão. Pode indicar que uma atividade chegou neste ponto e foi subdividida em mais de uma atividade (fork). Caso diversas atividades chegem neste ponto e saiam para uma única atividade. O símbolo chama-se Join. Símbolo de início ou entrada em um fluxo de atividades. Pode haver vários pontos de entrada para um processo. Símbolo de saída de um processo. Pode haver diversos pontos de saída para um processo. Fluxo final. O X dentro do símbolo indica o final de um fluxo que não seja uma saída normal do processo.
act Use Case Model
Swimlanes: este símbolo reproduz as raias de uma piscina. Indica o confinamento de um conjunto de atividades em uma determinada área da empresa. É usada para organizar logicamente uma atividade.
A figura 50 mostra um exemplo da aplicação do diagrama de atividade.
92
Modelagem de Processos
Avaliar item em estoque Registrar pedido Autorizar forma de pagamento
Cancelar pedido
OK?
Aceitar pedido
Figura 50 – Exemplo de diagrama de atividade
6.3 Diagrama de sequência
O diagrama de sequência mostra os objetos e as mensagens sendo trocadas entre eles, necessárias para a execução de uma determinada tarefa, evidenciando a ordem em que as coisas acontecem, sem mostrar as associações entre os objetos. Um diagrama de sequência é uma representação estruturada de comportamento com uma série de etapas sequenciais ao longo do tempo. Ele é usado para descrever o fluxo de trabalho, passagem de mensagens e mostrar como elementos em geral cooperam no tempo para alcançar um resultado. Esse diagrama pode ser usado para mostrar a evolução de uma dada situação em um determinado momento do software, mostrar uma dada colaboração entre duas ou mais classes e pode, também, ser usado para mostrar a tradução de um caso de uso, desde a interação com o usuário até a finalização daquele dado processo (MEDEIROS, 2004). Os objetos são mostrados na parte superior do gráfico e, para cada objeto, é desenhada uma linha vertical, que representa sua linha de vida. As mensagens são representadas por setas horizontais que ligam os objetos por meio de suas linhas de vida, a ponta da seta aponta para o objeto alvo. O eixo vertical normalmente aponta para baixo, indicando que as mensagens vão ocorrendo de cima para baixo na sequência de eventos. Cada elemento da sequência é organizado em uma sequência horizontal, com mensagens que passam para trás e para frente entre os elementos. 93
Unidade III Um elemento de ator pode ser usado para representar o usuário que inicia o fluxo de eventos. Elementos estereotipados, como interface, controle e entidade, podem ser usados para ilustrar as telas, os controladores e os itens de banco de dados, respectivamente. Cada elemento tem uma linha pontilhada tronco chamada de linha da vida do objeto ou elemento, na qual o elemento/objeto existe e, potencialmente, participa das interações. A figura 51 mostra um diagrama de sequência de um evento em que uma pessoa está telefonando, essa pessoa é chamada de chamador. Os objetos telefone chamador e telefone chamado também interagem para que o telefonema aconteça. sd Use Case Model
Telefone chamador
Chamador chamador levanta receptor( )
Telefone chamado Linha de vida do objeto
sinal de discar começa ( ) disca ( ) Ativação
disca ( ) disca ( ) telefone ocupado ( ) som da campainha ( )
telefone toca ( ) atenda telefone ( )
telefones interligados ( )
telefones interligados ( ) pessoa chamada desliga ( ) conexão desfeita ( )
conexão desfeita ( ) chamador desliga ( )
Figura 51 – Exemplo de diagrama de sequência
94
Modelagem de Processos 6.3.1 Linha de vida As linhas pontilhadas na vertical representam a existência do objeto em um determinado tempo. Se uma determinada mensagem representa a criação da instância do objeto, sua linha de vida iniciase naquele ponto. Se ela representa a destruição do objeto, a linha termina nesse ponto e a sequência termina. Se o objeto existe durante todo o processo, a linha de vida permeia todo o espaço vertical do diagrama. A linha de vida pode se bifurcar em duas ou mais linhas concorrentes para mostrar condicionalidades. 6.3.2 Ativação Uma ativação evidencia o período de tempo em que um objeto está executando uma ação, diretamente ou a partir de um procedimento subordinado. A ativação é representada por um retângulo de base pequena e cuja altura representa o tempo da ação (o topo do retângulo coincide com o início da ação e a base com o seu fim). A ação a ser executada pode ser colocada em uma etiqueta na proximidade da ativação ou na margem esquerda do diagrama, ou estar implícita na mensagem que aciona a ativação. 6.3.3 Autodelegação Evidencia a mensagem cujo objeto emissor (remetente) coincide com o objeto alvo (destinatário). Trata-se de uma chamada recursiva. Se a chamada recursiva se der sobre uma ativação, desenha-se outro retângulo aninhado com o primeiro, para mostrar a autodelegação. 6.3.4 Mensagem Uma comunicação entre objetos, que leva informação com a expectativa de que resultará em uma atividade. O recebimento de uma mensagem é normalmente considerado um evento. Mensagem é a unidade fundamental da comunicação entre objetos. A recepção de uma mensagem causa a invocação de uma operação no recebedor (objeto alvo). Esse executa o método da classe que corresponde àquela operação. 95
Unidade III As mensagens são representadas por setas nomeadas, colocadas nas proximidades da ligação, que ligam os objetos por meio de suas linhas de vida. A ponta da seta aponta para o objeto alvo. Quando um objeto for acionar uma mensagem nele mesmo, a seta inicia-se e termina no mesmo objeto. A implementação de uma mensagem pode tomar várias formas: a chamada procedure, a passagem de sinal entre threads ativas, o específico acionamento de um evento etc. 6.4 Diagramas de estado (máquina de estado)
O diagrama de estados representa, para uma determinada classe de objetos, seu padrão de eventos, estados e transição de estados. Um diagrama de estados é uma rede de estados e eventos. Na realidade, somente constrói-se diagrama de estados para as classes que possuem comportamento dinâmico importante. 6.4.1 Estado Um estado é uma abstração dos valores de atributos e ligações de um objeto. Por exemplo: a linha telefônica está no estado sinal de discar. Caso o dígito seja discado, a linha muda de estado, indo para o estado discando. Se o usuário recolocar o telefone no gancho, a linha telefônica passa do o estado sinal de discar para o estado inativa. Os conjuntos de valores podem ser agrupados em um estado de acordo com propriedades que afetam o comportamento geral do objeto. Por exemplo: o fato do estado de um banco ser de solvência ou de insolvência depende do seu ativo exceder o seu passivo. Com o passar do tempo, os objetos estimulam uns aos outros, resultando em uma série de alterações em seus estados. 6.4.2 Notações Na UML, o estado é representado por um retângulo, como no diagrama de atividades. Um retângulo com o nome do estado representa um estado simples. Um retângulo maior designa um estado composto ou máquina de estados. Quando outros estados (simples) estão participando de determinado composto, são desenhados em seu interior.
96
Modelagem de Processos
Pseudo_estado_inicial Estado_composto
Estado_simples
Est_simples 1
Est_simples 2
Pseudo_estado_final
Figura 52 – Símbolos do diagrama de estado
6.4.3 Evento Um estímulo individual de um objeto A que o objeto B reconhece e reage é um evento. Objeto A
Objeto Estímulo
B
Figura 53 – Evento entre objetos
O objeto B reage ao estímulo dependente de seu estado. Ele pode modificar seu estado, pode enviar resposta para o remetente ou acionar outro objeto, a partir de novos eventos e estímulos. Os eventos possuem os seguintes tipos: mensagem, tempo transcorrido e condição de guarda. Um evento é algo que acontece em um certo momento com os objetos de uma classe. Por exemplo: um usuário aperta o botão cancelar, o cliente desconta um cheque. Um evento pode logicamente preceder ou suceder outro evento. Dois eventos podem não estar relacionados, nesse caso, são chamados de concorrentes. Cada evento é uma ocorrência única, que pode ser agrupada em classes de eventos. Cada classe de eventos recebe um nome para indicar estrutura e comportamentos comuns. O exemplo a seguir demonstra uma classe de eventos: • O voo 100 parte de São Paulo. • O voo 200 parte de Fortaleza. • O voo 30 parte de Porto Alegre. 97
Unidade III Pode-se criar a classe partida de aviões e tratar esses voos como instâncias da classe. Os atributos dessa classe seriam: linha_aérea, número_do_voo, cidade_origem, cidade_destino etc. A Figura 54 mostra exemplos de classes de eventos: Partida_aviões
Botão_do_mouse_ levantado
Empresa_aerea Número_do_voo Cidade_destino
Botão localização
Altera_destino() Figura 54 – Exemplo de classes de eventos
6.4.4 Transição A modificação de estado causada por um evento é chamada de transição. A reação de um objeto a um evento pode constituir-se de uma ação que provoca uma modificação de estado no objeto. Um estado corresponde ao intervalo entre dois eventos recebidos por um objeto. Os eventos correspondem a “pontos no tempo”, e os estados representam “intervalos no tempo”, como mostra a Figura 55. Estados de um objeto t (objeto) Evento 1
Evento 2
Figura 55 – eventos e estados
Na definição de estados, ignoram-se os atributos que não afetam o comportamento dos objetos. Englobam-se em um só estado todas as combinações de valores de atributos e ligações que apresentam a mesma reação dos eventos. O diagrama de estados ou diagrama de máquina de estados determina ou específica a sequência de estados causada por uma sequência de eventos. A Figura 56 mostra um exemplo de eventos para uma classe conta de cliente de um banco.
98
Modelagem de Processos
Inativa Depósito_Cliente Mensagem rejeitado
Depósito_Rejeitado
Depositando
Depósito_Aceito Ativa
Figura 56 – Exemplo de um diagrama de estado
Um diagrama de estados é uma fonte de descoberta de operações. Ajuda a descobrir também novos estados, regras de integridade e definir com mais precisão os domínios dos atributos envolvidos. A figura 56 mostra um exemplo de um sistema de biblioteca.
Cadastramento Publicação indisponível Empréstimo de todos exemplares
Correção de erros de digitação
Liberação da publicação Publicação disponível
Devolução do empréstimo Retirada por empréstimo
Depósito_Aceito
Indisp. temporária (alienada)
Figura 56 – Diagrama de estados
Saiba mais Vale a pena ler o material disponível no endereço: . Este material está baseado no livro Princípios de análise e projeto de sistemas com UML, de Eduardo Bezerra, 2ª ed., Editora Campus/Elsevier. 99
Unidade III
Resumo Esta unidade apresentou conceitos da modelagem comportamental dos sistemas de informação. Diversos diagramas e modelos da UML são utilizados para se modelar os comportamentos dos sistemas, mas esta unidade deu ênfase ao modelo de caso de uso que, para alguns autores, é o principal modelo de UML, juntamente com o modelo de classes de objetos. Como os modelos estruturais são fundamentais para se definir a estrutura de um sistema, sua composição e dependências, os modelos comportamentais mostram as ações que durante o tempo acontecem com o sistema e com os atores que com ele interagem. A UML apóia o processo de desenvolvimento UP (Unified Process). Ele é considerado um processo use case driven, o que significa um processo dirigido por casos de uso. O modelo de caso de uso mostra o sistema realizando uma sequência de ações, para receber entradas dos usuários e gerar saídas para responder as necessidades do negócio. Daí a sua importância no desenvolvimento moderno e a ênfase dada a ele nesta unidade. De todos os diagramas da UML, juntamente com o diagrama de casos de uso e o diagrama de classes, o diagrama de sequência é considerado um dos mais importantes, principalmente no momento da programação. Com ele, pode-se passar a ordem e a sequência de chamadas dos objetos para resolver determinada lógica ou cenário de um caso de uso. Por sua vez, o diagrama de estado descreve o comportamento de um objeto de uma determinada classe de objetos. Já com o diagrama de estados, são modelados os eventos que podem ser representados como operações nos modelos de objetos. O modelo dinâmico de uma classe é herdado por suas subclasses. As subclasses herdam os estados e as transições de seus ancestrais. As subclasses podem ter seus próprios diagramas de estado.
100
Modelagem de Processos
Exercícios Questão 1. Os processos de desenvolvimento de software que se baseiam na UML como linguagem de modelos denominam o modelo de caso de uso como o orientador do processo (use case driven). Nesse modelo, temos três elementos considerados básicos: o Ator, o Caso de Uso e a Associação entre o ator e o caso de uso. O ator é usado para definir o papel que um utilizador ou usuário representa relativamente ao sistema de informação modelado. Ele representa um conjunto coerente de papéis que os usuários de casos de uso desempenham quando interagem com esses casos de uso. Pode-se afirmar que um ator representa um papel que um ser humano, um dispositivo de hardware ou até outro sistema desempenha com o sistema. A UML define que um usuário do sistema representado pelo ator pode ser: uma pessoa; outro sistema de informação; um equipamento hardware especializado; a passagem de tempo. Considerando-se os conceitos apresentados sobre a UML, analise as afirmações a seguir e assinale a alternativa incorreta: A) Na UML, o modelo de caso de uso é importante, já que auxilia na captura de requisitos do sistema que será construído. B) Os casos de uso de um diagrama de Caso de Uso representam as funcionalidades que serão implementadas em um sistema de informação. C) Os atores representam o ambiente externo do sistema (seres humanos, máquinas, agrupamentos lógicos, outros sistemas). D) Como a UML apresenta modelos e elementos na tecnologia OO, pode-se afirmar que um Ator é uma classe de objetos. E) O ícone que representa um ator no diagrama de casos de uso é um retângulo com diversos segmentos. Resposta: Alternativa E. Na UML, o modelo de caso de uso descreve como os usuários do sistema (entidades externas ao sistema), interagem com o sistema enviando ou recebendo informações. Análise das alternativas A) Correta. Quando o analista de sistemas precisa representar as necessidades do cliente ou usuário, utiliza o modelo de caso de uso da UML; este permite ao usuário mapear os requisitos em torno dos usuários e das funcionalidades do sistema. B) Correta. No modelo de caso de uso, o elemento que representa as funcionalidades do sistema e que executará os requisitos do sistema é o próprio caso de uso. 101
Unidade III C) Correta. Como os atores estão fora do sistema e interagem com o mesmo modelo de Caso de Uso, representam o ambiente externo do sistema. D) Correta. Todos os elementos de todos os modelos da UML representam objetos que podem ser instanciados na execução do sistema. O ator que representa os usuários do sistema também será instanciado na execução do sistema. E) Incorreta. O ícone que representa um ator no diagrama de caso de uso é a figura do stick man ou o homem palito. Questão 2. Os casos de uso em um modelo de caso de uso podem ser expandidos por meio de outros para mostrar comportamentos especiais e de extensão que complementam os cenários do caso de uso básico modelo. Considerando-se os conceitos apresentados sobre o modelo de caso de uso, analise as afirmações a seguir e assinale a alternativa incorreta: A) Um modelo de casos de uso é um modelo das funções pretendidas do sistema e suas vizinhanças, que serve como contrato entre o cliente e os desenvolvedores. B) Há muitas maneiras de modelar um sistema, cada uma pode atender a uma finalidade diferente, e o modelo de caso de uso, por ser facilmente compreendido, torna-se uma ferramenta poderosa de comunicação entre as pessoas envolvidas com o sistema. C) Os usuários e qualquer outro sistema que pode interagir com o sistema sendo modelado com o diagrama de caso de uso são os atores. D) O modelo de casos de uso não é uma ferramenta útil na negociação entre os desenvolvedores e os clientes/usuários devido à sua complexidade técnica. E) Os casos de uso são desenvolvidos com base nas necessidades dos atores. Isso garante que o sistema será o que os usuários esperam. Resolução desta questão na plataforma.
102
MODELAGEM DE PROCESSOS
UNIDADE III Questão 2 Resposta correta: alternativa D. Justificativa: quando uma funcionalidade (caso de uso) for complexa, propõe-se uma decomposição em funções mais detalhadas, entretanto, um dos pontos mais difíceis é aprender como determinar em que nível de detalhe os casos de uso devem "começar e terminar". Os casos de uso ou os requisitos do software devem estabelecer "o que" o sistema executa, mas não "como" ele executa. A) Correta. Quando o modelo de caso de uso é criado, ele deve ser aprovado pelo cliente ou usuário do futuro sistema. Dessa forma, ele pode ser usado para garantir aos clientes ou aos usuários que a equipe entendeu o problema e que vai tomar uma solução adequada. B) Correta. O modelo de caso de uso foi desenvolvido para facilitar a comunicação da equipe de desenvolvimento entre os seus componentes e com os clientes ou usuários do sistema. Dessa forma, ele é considerado uma ferramenta de comunicação no processo de desenvolvimento de sistemas. C) Correta. O Ator representa os usuários que irão interagir com o sistema, seja por meio da entrada de dados ou como receptor das saídas do sistema. D) Incorreta. O modelo de casos de uso é um dos modelos mais simples da UML, sendo que essa simplicidade e os poucos símbolos gráficos permitem que pessoas sem grandes conhecimentos técnicos em sistemas consigam interpretá-lo. E) Correta. O modelo de caso de uso tem por finalidade mapear as necessidades ou os requisitos de um sistema e é a ferramenta de comunicação entre os envolvidos com o sistema.
Modelagem de Processos
Unidade IV 7 MODELAGEM DA ARQUITETURA DE NEGÓCIO 7.1 Introdução
Processos de negócio são atividades previamente estabelecidas que têm como objetivo determinar a forma como o trabalho é realizado numa organização. Constituem um conjunto de ações, relacionadas entre si de forma lógica e coerente, a fim de promover uma saída favorável à organização, tanto em termos internos como externos. Uma estrutura de processos de negócio mal concebida pode por em risco a eficiência e a eficácia de uma empresa por meio dos produtos e serviços que gera e disponibiliza. Dada a similaridade das suas composições, função de negócio e processo de negócio são conceitos que frequentemente suscitam dúvidas entre as pessoas interessadas em formar um melhor entendimento a respeito dos elementos de uma arquitetura de negócios. Ambos são “coisas que a empresa faz”, entretanto, os processos são transfuncionais (ou horizontais), já que perpassam diversas barreiras funcionais dentro da organização (por exemplo: adquirir bem, alienar bem, contratar funcionário), enquanto que as funções, que em conjunto descrevem a missão da empresa, são verticais (por exemplo: contabilidade, vendas, logística). Um outro aspecto relevante, e que pode representar uma mais valia na implementação dos processos de negócio numa organização, tem a ver com a implementação de um sistema de informação bem estruturado. A existência de uma boa rede de informação, entre todos os intervenientes nos processos de negócio da organização, é condição sine qua non, uma vez que permite a comunicação em tempo real, tornando possível uma adequada tomada de decisão, resultante do ajuste contínuo de procedimentos que irá repercutir em toda a dinâmica organizacional e, consequentemente, na excelência dos seus resultados. Desse modo, quando se fala em processos de negócio, a abrangência é enorme, pois o seu âmbito de atuação é transversal e atua em todas as áreas da organização, com elevado impacto na qualidade dos serviços e/ou produtos, na redução de custos e no desenvolvimento do próprio negócio. Por outro lado, a existência de uma interface entre os processos de negócio e uma rede de sistemas de informação constituem fatores-chave fundamentais, quer para a generalidade dos negócios dos tempos de hoje, quer para a produção de indicadores e instrumentos de controle efetivo para uma constante monitorização das atividades da organização. 103
Unidade IV Assim, como a Figura 57 sugere, pode-se definir processos de negócio como um conjunto de atividades desenvolvidas a partir de um objetivo predefinido que irá concretizar-se num resultado específico, em termos de produto ou serviço que se pretenda realizar. Pessoas
Objetivo
Equipamento
Informação
Processos de negócio
Resultado
Que tarefas específicas? Qual a prioridade? Quais os procedimentos? Figura 57 – Processos de negócio
7.2 Modelagem de negócio
Para compreender uma organização, é necessário entender seus processos de negócio. Profissionais da Tecnologia da Informação se empenham em construir soluções que têm por finalidade auxiliar a empresa na conquista de maior espaço no mercado globalizado. Nesse contexto, os processos são avaliados e, sempre que possível, informatizados, de forma a promover vantagens competitivas a partir do alinhamento estratégico entre o sistema e o negócio da empresa. Para a OMG (Object Management Group, 2005), um processo de negócio corresponde a um conjunto coeso de atividades que criam um resultado, o qual garante a criação de valor a um cliente externo ou interno à empresa, ou, visto de outra forma, pode ser um conjunto de tarefas regido por regras de negócio e que se desenvolve a partir de um determinado evento de negócio. Segundo Laudon e Laudon (2001), um processo de negócio refere-se à maneira pela qual o trabalho é organizado, coordenado e focado, para produzir um produto ou serviço de valor. De um lado, processos de negócios são fluxos de trabalhos concretos de materiais, informações e conhecimentos. De outro, referem-se também à maneira singular de as organizações coordenarem trabalho, informação e conhecimento, e de como a gerência prefere coordenar o trabalho. Já a modelagem de negócio é uma técnica de modelagem de alto nível, que surgiu das dificuldades identificadas pelos analistas de sistemas. 104
Modelagem de Processos É uma abstração voltada à realidade dos administradores, assim, estudiosos e pesquisadores da área de TI criaram uma técnica de modelagem de alto nível denominada de modelagem de negócio, que hoje é parte integrante no processo de desenvolvimento de software e que serviu para facilitar a comunicação com as pessoas que fazem parte do negócio mas não possuem conhecimentos de Engenharia de software. Observação Os autores Michael Hammer e James Champy afirmam: Um processo de negócio é uma coleção de atividades que usam um ou mais tipos de entrada e criam uma saída que seja de valor para o cliente. Um processo de negócio tem um objetivo e é afetado por eventos que ocorrem no mundo externo ou em outros processos.
Lembrete A técnica de modelagem de negócio é profundamente relacionada à arquitetura de negócios. Observação Já o autor Thomas Davenport aponta que o processo de modelagem de negócios: [...] é um conjunto estruturado de atividades, desenhado para produzir um resultado especificado para um cliente ou um mercado em particular. Isso implica forte ênfase sobre como o trabalho é feito dentro da organização, em contraste com o foco no produto. Um processo é então uma ordenação específica de atividades de trabalho, por meio do tempo e do espaço, com começo e fim e entradas e saídas claramente dentificadas: uma estrutura para ação. 7.2.1 Conceitos de negócio Funções de negócio são estruturas conceituais idealizadas que servem para descrever a missão de uma organização. Uma vez que tenham sido definidas e decompostas adequadamente, elas se mantêm estáveis ao longo do tempo, mesmo diante de reorganizações da empresa. Como são perenes, as funções representam um ponto de referência (conceitos comuns) ao se descrever diferentes negócios, que de outra forma exibiriam variações significativas. 105
Unidade IV A Figura 58 exemplifica o relacionamento dentro de uma organização entre as funções de negócio e os processos de negócio a partir das atividades organizacionais e atividades de processos. act Business Process Model
Função de negócio
Atividade de negócio Atividade componente do processo
Processo de negócio
Subprocesso componente de processo
Figura 58 – Função de negócio, processo de negócio e seus relacionamentos
Como exemplo da aplicação dessa definição, temos o fato de que a função contabilidade de uma empresa define o contador, a função gerencial define o gerente e assim por diante. Funções de negócio são também alocadas a unidades ou áreas organizacionais específicas (que exercerão os diferentes papéis) e são envolvidas e acionadas no decorrer do “comportamento” do negócio. A Figura 58 mostra que uma função corresponde a uma série de atividades relacionadas, envolvendo uma ou mais entidades de dados, realizadas com o objetivo de se cumprir um ou mais objetivos da missão da empresa. As atividades de negócio que compõem uma função de negócio são relacionadas entre si por “afinidade”, porque trabalham um grupo comum de entidade de dados (clientes e produtos) ou porque são sequenciais ou paralelas na realização do trabalho associado a um resultado final comum. Observação A arquitetura de negócio busca uma visão conceitual e única de uma atividade ou funcionalidade, de forma que se possa identificar quando e como ela se repete nos diversos processos de negócio, a fim de determinar 106
Modelagem de Processos a generalização dos conceitos de tarefas comuns, identificando atividades compartilhadas e administrando seu reuso por meio da distribuição dos componentes que as suportam. Da mesma forma, os sistemas de informação que suportam tais funções estarão focados em aspectos específicos do funcionamento do negócio, independentemente da forma como a empresa está organizada. As atividades são direcionadas a dados e são “iniciadas” por transações ou solicitações de dados. Elas são a porção ativa das funções e tendem a ser repetitivas e formalizadas. Observação É importante notar: • Uma maneira de se diferenciar o conceito de funções e atividades é que, geralmente, as funções são gerenciadas e atividades são realizadas. • Funções são gerenciais e atividades são operacionais. Já um processo de negócio é definido como a sequência completa de um comportamento de negócio, provocado por algum evento, que produz um resultado significativo para o negócio e que, de preferência, tenha foco no cliente. No percurso do processo, desde o evento inicial até a produção de um determinado resultado, várias funções do negócio podem estar envolvidas. Assim, diz-se que os processos são elementos transfuncionais, já que perpassam diversas funções dentro da organização. Se uma função é composta de atividades que representam um papel ou razão de existir da organização, os processos de negócio “executam” essas atividades de forma que, individualmente ou combinadas, realizem o trabalho de uma determinada função. Um estudo de aplicação de modelagem de processo de negócio para apoiar a especificação de requisitos de um sistema Antes de entrarmos em duas notações de modelagem de processos seria interessante analisarmos os resultados obtidos com a aplicação da modelagem apresentada no artigo Um estudo de aplicação de modelagem de processo de negócio para apoiar a especificação de requisitos de um sistema, dos autores Adriana Andrade, Andriele Ribeiro, Eduardo Borges e Wolber Neves, apresentado no VI Simpósio Internacional de Melhoria de Processos de Software, em São Paulo, em 2004. 107
Unidade IV No item resultados obtidos, os autores afirmam: A aplicação da modelagem de processos de negócio trouxe resultados bastante positivos. A execução dessa etapa antes da realização do levantamento dos requisitos do sistema foi um fator de redução de riscos, tanto para o cliente quanto para o fornecedor. O cliente pôde ter uma visão melhor do seu negócio, identificando as áreas que realmente seriam beneficiadas pela construção do sistema, evitando assim o desperdício de recursos. Foi interessante observar que, durante as oficinas, o cliente pôde perceber que determinados processos não estavam sendo executados da melhor forma. Diante desta percepção, alguns processos foram remodelados, evitando que o sistema fosse construído sobre uma base operacional deficiente. Para o fornecedor, a execução da modelagem de processos de negócio resultou em maior facilidade na gestão dos requisitos do sistema. Muitas das constantes mudanças que ocorrem durante o desenvolvimento de um sistema decorrem da inexistência de um consenso entre os representantes do cliente sobre a melhor forma de se executar um processo. A modelagem de processos de negócio fez com que esse consenso fosse alcançado antes do início do levantamento dos requisitos do sistema, tornando esta etapa mais eficiente. A identificação dos casos de uso do sistema (UML) também foi bastante facilitada. Como passaram a conhecer melhor a realidade do cliente, os engenheiros de requisitos puderam ser mais proativos nessa atividade, contribuindo com sugestões e ponderações baseadas em conhecimento mais sólido. Esta proatividade mostrou-se especialmente útil nas primeiras oficinas, já que naquele momento os representantes do cliente ainda não estavam totalmente seguros com a metodologia de levantamento dos requisitos. Outro benefício trazido pela modelagem de processos de negócio diz respeito à rastreabilidade dos requisitos. Uma característica de qualidade importante para uma especificação de requisitos é a facilidade em se determinar os resultados do desenvolvimento que serão afetados por cada requisito (rastreabilidade para frente), bem como a origem de cada um (rastreabilidade para trás). Como os requisitos foram derivados diretamente do modelo de processos de negócio, a rastreabilidade para trás foi garantida documentando-se, para cada requisito, o processo de negócio que o gerou. Um ponto importante no desenvolvimento de um sistema, especialmente quando seu porte não é pequeno, é a sua divisão em produtos. A divisão é uma maneira formal de se 108
Modelagem de Processos exercitar o desenvolvimento incremental, já que produtos coesos e de menor porte são entregues em menor tempo do que um único módulo que contemple todas as funções. Isto é importante tanto do ponto de vista técnico quanto do de negócio, já que muitas vezes o cliente não dispõe de recursos para construir todo o sistema de uma só vez, e a priorização de requisitos dentro de um módulo único não é uma tarefa simples. Esse foi também um ponto em que a modelagem de processos de negócio foi benéfica. Antes de sua realização, cliente e fornecedor imaginavam que o sistema seria composto por três produtos. Após a modelagem, percebeu-se que o número de produtos era realmente três, mas a composição dos mesmos foi bastante modificada. Dois dos produtos foram agrupados em um único, e um produto de controle de fluxo de trabalho (workflow) foi identificado. Apenas um produto permaneceu conforme tinha sido concebido no início. A divisão inicial dos produtos espelhava a divisão funcional da empresa, o que não se mostrou uma boa idéia do ponto de vista de sistemas. A modelagem de processos de negócio fez com que cliente e fornecedor percebessem que duas das áreas eram muito integradas, o que justificaria um único produto para atendê-las. Da mesma forma, o problema de controle de fluxo de trabalho era comum a todas as áreas funcionais, o que justificaria um produto genérico para este fim, e não a inserção de funcionalidades correlatas em um dos produtos específicos para determinada área. Após a divisão dos produtos, um deles foi escolhido para ser especificado e construído. Seria necessário, portanto, realizar uma estimativa do tamanho do produto em pontos de função, para orçar-se a fase de elaboração. O melhor conhecimento da organização, conseguido por meio da modelagem de processos de negócio, também foi fundamental para que essa estimativa fosse bem próxima da contagem oficial de pontos de função, realizada alguns meses depois (após o fim da elaboração). Percebeu-se inclusive que a aproximação do número real foi maior do que em projetos em que a modelagem de processos de negócio não foi usada. Como último resultado importante, podemos citar o artefato resultante da modelagem de processos de negócio. Esse documento é importante para o cliente, já que é a documentação dos processos da organização. Mas também do ponto de vista do fornecedor o documento foi de grande utilidade, pois serviu para dar uma visão geral às pessoas que entravam no projeto depois de seu início. Foi uma forma simples e barata de integrar novas pessoas à equipe. Adaptado de: . Acesso em: 13 jul. 2012.
109
Unidade IV 7.2.2 Extensão de negócio da UML Segundo Paul e Serrano (2003), o estudo sobre processo de negócio não deve ser isolado, sendo importante seu relacionamento com a área de TI, pois ela é considerada sua grande modificadora. O processo de negócio geralmente confia no suporte fornecido pelos Sistemas de Informação (SI) para a realização de suas atividades. Similarmente, esses sistemas dependem da infraestrutura de comunicação, normalmente oferecido por rede de computadores (RC). A Figura 59 demonstra o relacionamento existente entre processos, sistemas de informação e redes de computadores, no qual mudanças ocorridas em alguns dos domínios devem afetar os demais. Processo1
Processo2 SI2
SI1
TI
Processon
RC1
...
SIn
RCn
Figura 59 – Relacionamento de processos, Sistemas de Informação (SI) e Redes de Computadores (RC)
De acordo com Dalal et al (2004), muitas técnicas para modelagem dos processos empresariais, incluindo DFDs (Diagramas de Fluxo de Dados), Idef0 (Definições Integradas para Modelagem por Funções, em nível 0) e diagramas de casos de uso de negócio, têm suas raízes nos processos de desenvolvimento de software. De acordo com as orientações da UML 2.0 Superstructure Specification, disponibilizada a partir de outubro de 2004 pela OMG, os casos de uso são meios de especificar os requisitos de um sistema de informação. Todavia, quando casos de uso documentam processos de negócio de uma organização, o Sistema sob Discussão (SsD), do inglês System under Discussion (SuD), é a própria organização. Os stakeholders ou atores de negócio são os acionistas da companhia, clientes, vendedores e as agências governamentais regulamentadoras. Os atores primários incluem os clientes da companhia e talvez seus fornecedores. Um caso de uso apenas documenta um processo, ele não faz reEngenharia, ou seu projeto novamente (COCKBURN, 2005). Um caso de uso especifica o comportamento de um sistema ou de parte de um sistema e é uma descrição de um conjunto de sequências de ações, incluindo variantes realizadas pelo sistema para produzir um resultado observável do valor de um ator. 110
Modelagem de Processos Além disso, os casos de usos podem ser aplicados para captar o comportamento pretendido do sistema que está sendo desenvolvido, sem ser necessário especificar como esse comportamento é implementado. Também fornecem uma maneira para os desenvolvedores chegarem a uma compreensão comum com os usuários finais do sistema e com os especialistas do domínio e servem para ajudar a validar a arquitetura e para verificar o sistema à medida que ele evolui durante seu desenvolvimento (BOOCH et al, 2000). Quando utilizados para representar processos de uma organização, os casos de uso são identificados como casos de uso de negócio. Em outras palavras, um caso de uso de negócio representa o que a organização faz (BOGGS e BOGGS, 2002). O escopo de um caso de uso pode abranger uma escala de assuntos: • Uma empresa ou uma linha de negócio: este nível de modelo é utilizado para descrever como os sistemas se integram. • Um sistema individual: este é o nível mais utilizado na abordagem por casos de uso. • Um simples subsistema simples ou componente: este nível descreve os mecanismos de implementação de um elemento do modelo. • Para descrever um processo de trabalho de um negócio. • Para focar discussão sobre futuros requisitos de software. • Para ser os requisitos funcionais de um sistema. • Para documentar o projeto do sistema. • Para ser escrito em um grupo pequeno e restrito, ou em um grupo grande ou distribuído. O modelo de casos de uso de negócio é um modelo das funções pretendidas do negócio. É usado como base para identificar papéis e produtos liberados na organização. Os casos de uso de negócios são identificados e possivelmente resumidos no início da fase de iniciação, para ajudar a definir o escopo do projeto (RUP, 2001). Quadro 8 – Propriedades de um caso de uso de negócio Nome da propriedade
Descrição
Nome
O nome do caso de uso de negócio.
Breve descrição
Uma breve descrição do papel e da finalidade do caso de uso de negócios.
Metas
Uma especificação das metas ou objetivos mensuráveis do caso de uso de negócios.
Metas de desempenho
Uma especificação das métricas relevantes ao caso de uso de negócios e uma definição das metas de utilização dessas métricas.
111
Unidade IV
Fluxo de trabalho
Uma descrição textual do fluxo de trabalho representado pelo caso de uso de negócios. O fluxo deve descrever o que o negócio faz para oferecer vantagens a um ator de negócio, e não como esse negócio resolve os problemas. A descrição deve ser compreensível para qualquer pessoa dentro do negócio.
Categoria
Se o caso de uso de negócios pertence à categoria central, suporte ou gerenciamento.
Risco
Uma especificação dos riscos de executar e/ou implementar o caso de uso de negócios.
Possibilidades
Uma descrição do potencial de melhoria estimado do caso de uso de negócios.
Proprietário do processo
Uma definição de quem é o proprietário do processo de negócios: a pessoa que gerencia e planeja as mudanças.
Requisitos especiais
As características do caso de uso de negócio não cobertas pelo fluxo de trabalho conforme descrito.
Pontos de extensão
Uma lista dos locais dentro do fluxo de eventos do caso de uso de negócios em que um comportamento adicional pode ser inserido por meio do relacionamento de extensão.
Relacionamentos
Os relacionamentos (como associações de comunicação, relacionamentos de inclusão e de extensão) dos quais o caso de uso participa.
Diagramas de atividades
Esses diagramas mostram a estrutura do fluxo de trabalho.
Diagramas de casos de uso
Esses diagramas mostram os relacionamentos que envolvem o caso de uso.
Ilustrações do fluxo de trabalho
Resultados ou esboços manuscritos provenientes das sessões de encenação. Adaptado de: RUP, 2001.
De acordo com o RUP (2001), os elementos de um modelo de caso de uso de negócio podem ser demonstrados conforme o quadro 9. Quadro 9 – Componentes do diagrama de caso de uso de negócio Nome
112
Notação
Descrição
Ator de negócio
Um ator de negócio representa um papel desempenhado em relação ao negócio por alguém ou algo no ambiente do negócio.
Caso de uso de negócio
Um caso de uso de negócios define uma instância de negócio, no qual cada instância é uma sequência de ações realizada por um negócio que produz um resultado de valor observável para um determinado ator de negócio.
Modelo de caso de uso de negócio
O modelo de casos de uso de negócios é um modelo das funções pretendidas do negócio. É usado como base para identificar papéis e produtos liberados na organização.
Modelagem de Processos
Generalização de ator
Um relacionamento de generalização de uma classe de ator de negócio (descendente) com outra classe de ator de negócios (ascendente) indica que o descendente herda o papel que o ascendente pode assumir em um caso de uso de negócios.
Associação de comunicação
Uma associação de comunicação entre um caso de uso e um ator indica que uma instância do caso de uso e uma instância do ator irão interagir.
Relacionamento de extensão
Um relacionamento de extensão é aquele que se estabelece entre um caso de uso de extensão e um caso de uso base, especificando como o comportamento definido para o caso de uso de extensão pode ser inserido no comportamento definido para o caso de uso de base. Ele é inserido implicitamente, ou seja, a extensão não é exibida no caso de uso base.
“extensão”
Um relacionamento de inclusão é aquele que se estabelece entre um caso de uso base e um caso de uso de inclusão, especificando como o comportamento definido para o caso de uso de inclusão é inserido de forma explícita no comportamento definido para o caso de uso base.
“inclusão”
Relacionamento de inclusão
Generalização de casos de uso
Uma generalização de casos de uso é um relacionamento de um caso de uso filho com um caso de uso pai, especificando como um filho pode adotar todo o comportamento e as características descritas para o pai.
Diagrama de casos de uso
Um diagrama de casos de uso mostra os atores de negócios, os casos de uso de negócios, os pacotes de casos de uso e seus relacionamentos.
De acordo com o RUP (2001), a projeção realizada pela Engenharia de negócio é fundamental para a realização do sistema. As atividades do negócio e os relacionamentos identificados entre elas, bem como a atuação dos envolvidos, determinarão os objetivos a serem alcançados pelo software a ser desenvolvido. A Figura 60 apresenta uma conexão entre essas duas áreas. Proposta para informatização Proposta de software Engenharia de processo de negócio
Engenharia de software
Modelo de negócio Figura 60 – O relacionamento entre Engenharia de processo de negócio e Engenharia de software
113
Unidade IV 7.2.3 Visões de modelos de negócio O modelo de negócios é a forma pela qual uma empresa cria valor para todos os seus principais públicos de interesse. Sua utilização ajuda a ver de forma estruturada e unificada os diversos elementos que compõem todas as formas de negócios da organização. O modelo de negócio de uma empresa é composto por 5 principais elementos: • Modelo de proposta de valor: é a forma pela qual a empresa define qual é o seu diferencial no mercado, a forma pela qual é única e se destaca de todas as demais empresas que participam desse mesmo mercado. • Modelo de interface com o consumidor: é o que escreve onde, quando e como uma empresa interage com os seus consumidores. Essa interação pode se dar por meio de lojas, embalagens de produtos, comerciais, SAC, website etc. • Modelo de operação: é como que uma empresa faz para levar o seu produto até o seu consumidor. Esse modelo deve prever todos as etapas necessária para viabilizar sua produção, passando por logística, até chegar às mãos de quem compra o seu produto ou serviço. • Modelo estratégico: é a descrição de como uma empresa irá atingir os seus objetivos estratégicos. Nesse modelo é onde visualiza-se a missão de uma empresa, sua visão, seus valores e todas as competências necessárias para que a empresa funcione de forma adequada. • Modelo econômico: é onde se demonstra a viabilidade financeira de uma empresa. Esse modelo mostra como uma empresa ganha recursos e paga suas despesas a fim de atingir a sustentabilidade. 7.3 OCL e sua utilização na modelagem de processo de negócio
A OCL (Object Constraint Language) é uma notação que permite se dar mais precisão nas especificações ou modelos que usam a UML. Lembrete A OCL é baseada na lógica e matemática discreta. Assim como a UML, é uma linguagem de modelagem e não uma linguagem de programação. É uma linguagem de modelos tipada. Inicialmente, a OCL era uma extensão para a UML, agora é parte da UML padrão.
114
Modelagem de Processos Por que a OCL? • Um diagrama UML, tal como o diagrama de classes, é tipicamente não refinado o suficiente para permitir-se ter todos os aspectos relevantes de uma especificação. • Há a necessidade de se descrever restrições adicionais sobre os objetos de um modelo. • A linguagem natural é inerentemente ambígua. • Linguagens formais tradicionais são dificíeis para usuários de negócio ou modeladores de sistemas. • A OCL é uma linguagem formal que permanece simples para ler e escrever. Quando se deve usar a OCL? • A linguagem OCL é usada para expressar condições constantes de restrições de especificações para sistemas que estão sendo modelados. • Para especificar invariantes nas classes e tipos no modelo de classes. • Para especificar tipos invariantes para estereótipos. • Para descrever pré e pós-condições nas operações e métodos. • Para especificar restrições nas operações. A OCL é suportada para os seguintes tipos de diagramas da UML 2.0, como mostrta a quadro 10. Quadro 10 – Diagramas com suporte OCL Tipo de diagrama
Versão da UML
Como o suporte é provido
Use case (caso de uso)
UML 2.0
Restrições para o comportamento associado com os casos de uso como expressões OCL. Por exemplo, uma interação escolhida como um comportamento.
Classes (classe, namespace e comunicação)
UML 1.5 e 2.0
Restrições na criação de objetos são suportadas.
Interação (sequência e comunicação)
UML 2.0
Restrições de invariância de estado para linhas de vida e restrições dos operandos de fragmentos combinados como expressões OCL.
Máquina de estado
UML 2.0
Condições de guarda de transições como expressões OCL.
Como os modelos de negócio são suportados pelos diagramas de casos de uso a OCL, esses apoiarão as restrições das pré e pós-condições para execução de um caso de uso de negócio. 115
Unidade IV 7.4 Integração com o desenvolvimento de software
Num processo iterativo de desenvolvimento de software, a equipe do projeto segue uma série de fases, cada uma focando diferentes partes do negócio ou sistema. Existem duas abordagens para a modelagem de negócio em um ambiente iterativo: • Primeiro, terminar toda a modelagem de negócio e, na sequência, iniciar as atividades iterativas (análise, design, codificação, teste e implantação). • Alternativamente, pode-se incluir a modelagem de negócio nas iterações (BOGGS e BOGGS, 2002). Para Boggs e Boggs (2002), tanto num processo iterativo, como num modelo de processo do tipo “cascata”, a modelagem de negócio surge nas fases iniciais. As razões pelas quais isso ocorre é que a modelagem de negócio determina o contexto para o projeto. As figuras 60 e 61 mostram o aparecimento da modelagem de negócio nos processos de desenvolvimento de software. Modelagem de negócio Análise
Implantação
Design Teste
Implementação
Figura 61 – Processo iterativo após o surgimento da modelagem de negócio
Modelagem de negócio
Análise
Implantação
Design Teste
Implementação
Figura 62 – Modelagem de negócio como fase integrante do processo iterativo
7.4.1 Processo de desenvolvimento de software Existem inúmeros caminhos para reproduzir modelos de negócio dentro dos processos de desenvolvimento de software, incluindo o uso de outras notações tais como Idef0 (modelagem funcional), ou mesmo descrições textuais do processo. 116
Modelagem de Processos No entanto, a UML é um padrão bem definido, suportado por muitas técnicas. É a linguagem de modelagem dominante, usada em sistemas de informação orientados a objeto. A UML é na atualidade o padrão que possui a melhor definição, suportada por muitas ferramentas e, dessa forma, tornou-se a linguagem de modelagem dominante na aplicação da tecnologia da orientação a objetos. Além disso, pode ser utilizada para a modelagem de negócio e também para a modelagem de outros sistemas, ou seja, para aqueles que não serão utilizados para o desenvolvimento de softwares (OMG, 2005). Para Widrig e Leffingwell (2003), os principais modelos para a modelagem de negócio são: business use-case e business object model. Diagramas num modelo de negócio ajudarão a compreender o que a organização fornece de valor, dentro de um relacionamento. Enquanto a maioria dos diagramas da UML foca no sistema que será construído, o modelo de casos de uso de negócio se concentra no negócio em torno desse sistema (BOGGS e BOGGS, 2002). O modelo de caso de uso de negócio consiste na interação entre atores e casos de uso, para demonstrar a sequência de eventos necessários na realização de um trabalho. Juntos, atores e casos de uso descrevem o que está envolvido nas atividades do negócio e também como ele ocorre (WIDRIG e LEFFINGWELL, 2003). 7.4.2 Arquitetura de negócio e arquitetura de software Um dos principais esforços da investigação relacionada com a Engenharia de software tem sido a definição e representação de modelos que descrevam os processos de software, garantindo que esses correspondam fidedignamente às necessidades efetivas (em forma e conteúdo) dos processos de negócio. Deparamo-nos então com duas realidades complementares: a modelagem dos processos de negócio e a modelagem do software, que também podem ser chamadas de arquitetura de negócio e arquitetura de software, na qual esta última tem cada vez mais a necessidade de estar em sintonia com toda a abrangência do negócio (RODRIGUES, 2004). As modelagens de negócio e de sistema (software) são frequentemente desenvolvidas como parte de dois diferentes projetos com dois diferentes times. Ambas devem possuir boa definição, pois são ferramentas importantes para o gerenciamento da complexidade da amplitude e dificuldade do sistema (PENKER e ERIKSSON, 2000). Rodrigues (2004), ao avaliar o contexto da modelagem de negócio para a modelagem de sistema, especifica que ainda existe um caminho a ser percorrido para que a ponte entre esses dois domínios seja estabelecida de forma suave e sem sobressaltos. 117
Unidade IV A Figura 63 mostra a integração proposta por Rodrigues (2004).
Modelagem do processo
Modelagem de sistema
O que existe para fazer a ponte efetiva entre modelagem de negócio e sistema? Figura 63 – Integração entre modelagem de negócio e sistema
No RUP (2001), a integração entre negócio e sistema tem início nas primeiras atividades da iteração do ciclo de desenvolvimento do sistema, definida como iniciação. Nesse momento, a maior parte dos esforços, para as disciplinas Modelagem de Negócios e Requisitos, é utilizada com o propósito de obter as informações necessárias para a condução do projeto e elaboração do software. A Figura 64 demonstra, no detalhe, o esforço necessário na fase inicial da iteração, a partir do desenho de visão geral do RUP.
Fases Disciplinas
Iniciação
Elaboração
Construção
Transição
Modelagem de negócios Requisitos Concentração de esforços nas fases iniciais. Figura 64 – O esforço da modelagem de negócios e requisitos
A Figura 64 mostra que as disciplinas de Modelagem de Negócios e Requisitos do Sistema são perfeitamente integradas e dependentes ao longo do processo de desenvolvimento iterativo RUP. Um conceito atual que vem sendo tratado pelos autores e as empresas de tecnologia é o gerenciamento de processos de negócio ou business process management. 118
Modelagem de Processos
Saiba mais Vale a pena conferir o documento Business Process Management Enabled by SOA, da IBM de 2009, em que o gerenciamento de processos de negócio é mais frequentemente associado com o ciclo de vida de um de processos de negócios. O ciclo de vida de processo de negócio abrange identificar e melhorar os processos que proporcionam capacidade de negócios para implantar e gerenciar os seus processos quando estiver operacional. O que é frequentemente esquecido é a gestão do desempenho do processo depois que é operacional. De certa forma, essa é provavelmente a fase mais importante do ciclo de vida de processos. Depois que um processo de negócio é implantado, ele deve ser gerenciado, e, para gerenciar o processo de negócio, deve-se ter visibilidade do desempenho de processos. Quando um processo não atingir mais o seu desempenho de seus objetivos, é hora de voltar ao ciclo de vida para avaliar a causa raiz do problema de desempenho e buscar oportunidades de melhoria adicionais. Subjacente, BPM é também governança. Governança é um componente essencial de BPM porque fornece a estrutura que garante que a estratégia de negócios e metas sejam implementadas no nível operacional. A estrutura de governança também permite negócio e alinhamento de TI, fornecendo mecanismos que aumentem a colaboração e cooperação entre os dois mundos, os processos de negócio e a tecnologia da informação. 8 A modelagem de processos de negócio 8.1 Visão Erikson e Penker
Antes que a OMG se preocupasse com a modelagem de negócios com a linguagem UML, os autores Erikson e Penker (2000) propuseram um metamodelo para a modelagem dos processos de negócio, o qual apresenta: • Uma visão de mais alto nível, visando identificar a situação do negócio que será abordada. • Nessa visão, deve-se definir o contexto e o escopo, sendo que: — o contexto é o que está relacionado, qual a situação, descrição do problema; e — o escopo é até onde vai, contorno ou limite. 119
Unidade IV • Essa visão pode incluir FCSs (Fatores Críticos de Sucesso). • As metas e objetivos (do original Goal) podem ser decompostos em diferentes níveis, como, estratégico/tático/operacional, sendo que: — o objetivo é qualificável; e — a meta é quantificável. Nesse modelo, os processos de negócio: • possuem uma meta; • possuem entradas e saídas específicas; • usam recursos; • possuem um número de atividades, realizadas em alguma ordem, que podem ser vistas como subprocessos; • afetam mais de uma unidade da organização; • criam valor para algum consumidor (interno ou externo). A figura 65 apresenta os elementos ou símbolos propostos para o modelo de Erikson e Penker. <> Processo A
<>
<>
<>
Subprocesso A1
Subprocesso A1
Subprocesso A1
Atividade A2a
Atividade A2b
Atividade A2c
Atividades podem ser entendidas como processos atômicos
Figura 65 – Notação de Erikson e Penker para modelagem de negócio
120
Modelagem de Processos As atividades ou processos atômicos são: • Diretas: diretamente envolvidas na criação do produto ou serviço, que é o valor criado pelo processo. • Indiretas: dá suporte às atividades diretas, como manutenção, administração etc. • Garantia de qualidade: atividades que garantem a qualidade de outras atividades, como inspeção, controle, revisão e validação. A figura 66 ilustra os passos de um processo de negócio nesta notação. <> Furação <> Fazer furo Ler instrução
Calibrar
Ligar furadeira
Furar
Processo contendo 3 subprocessos: dois atômicos e um composto Figura 66 – Passos de um processo
A figura 67 mostra um exemplo de um processo de negócio com recepção e emissão.
<>
Ordem de compra
Demanda do cliente por ação Ordem de venda
<> Administração de compra de ação
Compra de ação no mercado
<> Administração de venda de ação
Venda de ação no mercado
Figura 67 – Processo de recepção e emissão
121
Unidade IV Como novo exemplo, a figura 68 apresenta um modelo de processo de furação de chapas em uma indústria qualquer. <> chapas furadas por dia: Meta Quantitativa Valor = 100 <> <> instruções de fucação
<> furação
<> chapa de aço
<> chapa perfurada
Figura 68 – Exemplo de um processo de furação de chapa
A notação de Erikson e Penker ainda hoje é utilizada, e algumas ferramentas Case, tal como a ferramenta EA, mantêm essa notação. 8.2 A modelagem de processos de negócio com a BPM
A notação BPMN surgiu como um padrão alternativo à UML, também sendo gráfica, porém seus símbolos são um pouco diferentes, pois a BPMN (Business Process Modeling Notation) foi criada especificamente para modelar processos de negócio. Essa notação não oferece qualquer suporte para modelar dados, atores, estados de ciclo de vida, ou sistemas. Quem desenvolveu o BPMN foi o Business Process Management Initiative (BPMI), iniciativa oriunda da OMG que lançou a especificação 1.0 ao público em maio de 2004. Tanto a UML como a BPMN são notações mantidas pela OMG. Os objetivos do esforço do grupo que desenvolveu o BPMN são: • Fornecer uma notação que seja fácil. • Ser compreensível por todos os usuários de negócios. • Envolver os analistas de negócio, os desenvolvedores, os técnicos responsáveis pela aplicação dos sistemas que irão executar os processos e as pessoas de negócios. 122
Modelagem de Processos A BPMN define um Business Process Diagram (BPD), que é baseado em um fluxograma adaptado para a criação de modelos gráficos de tarefas dos processos de negócio. Para a BPMN, um modelo de processo de negócios é uma rede de objetos gráficos, denominados de atividades, e do fluxo de controle, que define a ordem de execução. As grandes empresas de software, tais como a IBM, a Oracle, a SAP e outras, vêm investindo em sistemas que automatizam a gestão de processos de negócio (execução, controle e monitoração). Esses sistemas são os denominados BPMS (Business Process Management Suite), que dão suporte ao mapeamento, execução, monitoração e controle dos processos de negócio de uma organização. Tipicamente, inclui: • o mapeamento dos processos de negócio ponta-a-ponta; • desenho dos fluxos e formulários eletrônicos; • definição de workflow; • regras de negócio; • integradores; • monitoração em tempo real das atividades; e • alertas. É uma poderosa ferramenta de gestão, para garantir que os processos estão sendo efetivamente executados como modelados, contribuindo para os objetivos da organização. Os softwares utilizados na operacionalização e gerenciamento de processos de negócio são um dos principais facilitadores da gestão do conhecimento referente ao processo, sendo considerada a maior facilidade para obtenção, distribuição e análise dos dados. Há algumas funcionalidades que podem ser disponibilizadas via software, inclusive nos softwares BPMS, que, quando disponíveis, aumentam a capacidade dos gestores e demais envolvidos com o processo em estabelecer uma troca de imagens e idéias, nos ambientes onde ocorre a geração do conhecimento. Observação A solução BPMS não propõe a substituição dos sistemas existentes na organização os conhecidos como “sistemas legados”, e sim disponibiliza um ambiente de integração de sistemas de informação, que permite definir: 123
Unidade IV • fluxo de execução; • regras; • eventos; • demais especificações necessárias à operação e gerenciamento do processo de negócio. Dessa forma, permite atender a outra característica do processo de negócio: a de ser extremamente dinâmico, permitindo, por exemplo, uma substituição rápida e simples de um software por outro, necessária quando uma empresa parceira da organização é substituída, demandando a integração com um novo software disponível no ambiente computacional do novo parceiro. De acordo com vários autores, um BPMS completo teria os seguintes módulos ou funcionalidades: • Funcionalidades mínimas para uma solução poder se classificar como BPMS: — ferramenta de modelagem e desenho do processo; — engenho de execução do processo; — orquestração de web services; — interface de workflow para usuários. • Para ter um produto mais completo, seria necessário: — suporte para regras de negócio complexas; — Business Activity Monitoring (BAM); — controle de versão dos documentos anexados a instâncias do processo. • E para um produto completo, seria acrescentado de: — Enterprise Service Bus (ESB); — Repositório de metadados; — Uma suite de business intelligence.
124
Modelagem de Processos Um BPD é formado por um conjunto de quatro elementos gráficos, que são: • objetos de fluxo; • objetos de conexão; • raias (swimlanes); e • artefatos. 8.2.1 Objetos de fluxo Um BPD apresenta três objetos de fluxo: evento, atividade e gateway. Os objetos de fluxo são os principais elementos gráficos para definir o comportamento de um processo de negócio. 8.2.1.1 Evento Um evento é algo que “acontece” no decurso de um processo de negócio. Esses eventos afetam o fluxo do processo e normalmente têm uma causa (trigger) ou um impacto (resultado). Somente os eventos têm a capacidade de iniciar ou terminar um processo, porém não executam tarefas nesse. Os eventos ainda podem forçar a execução ou desviar para uma determinada atividade. Há três tipos de eventos, com base em quando eles afetam o fluxo: evento de início, evento intermediário e evento de fim, com notação apresentada na figura 69. BPMN BPMN
Evento início
Evento intermediário
Evento fim
Figura 69 – Símbolos de eventos da BPMN
125
Unidade IV O evento início define a inicialização em um processo. O evento intermediário define um evento intermediário em um processo. Já o evento fim define o término de um evento em um processo. Um processo pode ser iniciado por diferentes circunstâncias. Essas circunstâncias são chamadas de gatilhos (triggers), tais como, uma mensagem chegando ou um temporizador. 8.2.1.2 Atividade Uma atividade organiza e especifica participação de comportamentos subordinados, tais como, as sub-atividades ou ações, para refletir o controle e o fluxo de dados de um processo. As atividades são usadas nos diagramas de atividades para vários propósitos de modelagem: para a modelagem do desenvolvimento de uma aplicação típica, para modelagem de um processo de negócio ou para modelar um workflow. Durante a criação, ou em edições mais tarde, uma atividade pode ser definida como um elemento composto. Contudo, quando se cria uma atividade composta, é possível usar também o elemento atividade estruturada, que foi criada para esse propósito. A especificação da OMG UML1 estabelece: • Uma atividade específica à coordenação da execução de comportamentos subordinados, usando um controle e modelo de fluxo de dados. • Os comportamentos subordinados coordenados por esses modelos podem ser iniciados porque outros comportamentos no modelo irão concluir a execução, ou porque os objetos e os dados ficam disponíveis, ou porque ocorrem eventos externos para o fluxo. • O fluxo de execução é modelado como atividades, os nós são ligados por arestas. Um nó pode ser a execução de um comportamento do subordinado, como um cálculo aritmético, uma chamada para uma operação, ou a manipulação do conteúdo do objeto. • Atividades podem formar hierarquias invocando outras atividades, em última análise, para resolver as ações individuais. Em um modelo orientado a objetos, as atividades são geralmente chamadas indiretamente de métodos vinculados às operações que estejam diretamente invocadas. • As atividades podem descrever processos de computação. Nesse contexto, são os métodos correspondentes às operações nas classes. As atividades podem ser aplicadas à modelagem organizacional para a Engenharia de processos de negócio e workflow. • Nesse sentido, eventos geralmente se originam de dentro do sistema, tais como o acabamento de uma tarefa, mas também de fora do sistema, como uma chamada de cliente. 1
126
UML Superestrutura Especificação, versão 2.1.1, p. 318.
Modelagem de Processos • As atividades também podem ser utilizadas para a modelagem de sistema de informação, para especificar os processos ao nível do sistema. As atividades podem incluir ações de vários tipos (funções primitivas, operações aritméticas etc.). Uma atividade é representada por um retângulo de bordas arredondadas e é um termo genérico para o trabalho que a empresa realiza. Uma atividade pode ser atômica (tarefa) ou não atômica (composta – subprocesso). analysis Diagrama Estrutura de Versão
Sub_processo
Atividade
+
Figura 70 – Atividade atômica e não atômica
8.2.1.3 Gateway Utilizado para controlar a divergência e convergência da sequência de fluxos, determina as decisões tradicionais de bifurcação, fusão e união de caminhos. Marcadores internos indicam o tipo de controle do comportamento. analysis Diagrama Estrutura de Versão
Figura 71 – Elemento gateway
Gateways são os mecanismos padronizados na notação BPMN para desvios. Eles controlam como o processo diverge ou converge, ou seja, representam pontos de controle para caminhos dentro do processo. Eles separam e juntam o fluxo de um processo por meio do fluxo de sequência. 8.2.2 Objetos de conexão Os objetos de fluxo são conectados ao diagrama pelos objetos de conexão, para criar o esqueleto estrutural básico de um processo de negócio. Um BPD tem três objetos de conexão: fluxo de sequência, fluxo de mensagem e associação. 127
Unidade IV 8.2.2.1 Fluxo de sequência Um fluxo de sequência é usado para mostrar a ordem (sequência) que as atividades são realizadas em um processo. A figura 72 mostra um exemplo de fluxo de sequência. BPMN BPMN
Atividade 1
Fluxo de sequência
Atividade 2
Figura 72 – Fluxo de sequência
8.2.2.2 Fluxo de mensagem Um fluxo de mensagem é usado para mostrar mensagens entre dois participantes do processo (entidades empresariais ou papéis de negócio) que enviam e recebem mensagens. BPMN BPMN
Atividade 1
Fluxo de mensagem
Atividade 2
Figura 73 – Fluxo de mensagem
8.2.2.3 Associação Uma associação é usada para associar dados, textos e outros artefatos com os objetos de fluxo. Associações são utilizadas para mostrar as entradas e saídas de atividades. analysis Diagrama Visão Estrutura de Versão
Documento
Activity2
IntermediateEvent3
Figura 74 – Associação
128
Modelagem de Processos A figura 75 mostra um exemplo de um pedaço de um processo utilizando os elementos apresentados. class BPMN
No EndEvent
StartEvent
Repeat for Each Supplier
YES
Send RFQ
Receive Quote
Limite do tempo excedeu
Add Quote
Marca que mostra que o subprocesso tem loop
Evento intermediário para um time out
Figura 75 – Exemplo de um processo
8.2.3 Raias (Swimlanes)
Swimlanes é um mecanismo para organizar atividades em categorias visuais separadas, que organizam as diversas capacidades ou responsabilidades. Os objetos swimlanes do BPD são: • Pool; • Lane.
Swinlanes ou raias ajudam a dividir e organizar atividades em diferentes categorias visuais em um diagrama, de forma a ilustrar diferentes capacidades funcionais ou responsabilidades. Pools são utilizados quando o diagrama envolve duas entidades empresariais e são separados fisicamente no diagrama. As atividades dentro de grupos separados são consideradas processos autocontidos. Os fluxos de sequência não podem cruzar a fronteira de um pool. Deve-se usar o fluxo de mensagem como mecanismo para mostrar a comunicação entre dois participantes em pools diferentes. 8.2.3.1 Pool
Pool representa um participante em um processo (pessoa, área, empresa, outro processo etc.). Atua como um container gráfico para o particionamento de um conjunto de atividades de um ou mais processos de um participante. 129
Unidade IV
Cliente
<>
class BPMN
Figura 76 – Exemplo de um diagrama com pool
8.2.3.2 Lane
Lane é uma subpartição dentro de um pool que vai se estender a todo comprimento do pool, tanto verticalmente quanto horizontalmente. Lanes são usadas para organizar e categorizar atividades. As lanes são elementos que são posicionados dentro de pools para indicar mais de um perfil que colaboram para a execução de um processo. Lanes criam subpartições para os objetos dentro de um pool. Essas participações são usadas para agrupar elementos do processo. São frequentemente usadas para separar as atividades associadas com uma função ou papel de uma determinada empresa. Os fluxos de sequência podem atravessar as fronteiras das lanes dentro de um pool. O fluxo de mensagem não pode ser usado entre fluxos de objetos nas lanes de um mesmo pool.
CAC
<> HELPDESK
Cliente
class BPMN
Figura 77 – Uma pool com duas lanes
A figura 78 mostra um exemplo de um BDP com duas pools, sendo que essas somente possuem uma lane cada. 130
Modelagem de Processos
PACIENTE Consultório Médico
<>
<>
class BPMN
Ocorre doença
Envia pedido médico
Recebe pedido sintomas
Eu quero ver o médico
Envia sintomas Eu me sinto doente
O médico pede sintomas
Envia pedido médico
Recebe receita
Recebe pedido sintomas
Pegue sua receita para comprar os remédios
Envia sintomas
Recebe receita
Figura 78 – Exemplo de pools e lanes juntas
8.2.4 Artefatos A notação BPMN permite aos modeladores o uso de extensões de notação. Um número qualquer de artefatos pode ser adicionado ao diagrama, conforme as necessidades apropriadas ao contexto de negócio sendo modelado. A versão corrente do BPMN predefine três tipos de artefatos BPD: • objeto de dados; • grupo; e • anotação. Os modeladores podem criar seus próprios tipos de artefatos, que podem adicionar mais detalhes sobre como o processo é executado. A figura 79 mostra um diagrama com lanes dentro de uma pool e com adicionamento de artefatos.
131
Unidade IV
Gerenciamento
Web Service
Administração
class BPMN
<> Prepara ordem de pagamento +
Informações pagamento
E-mail requisição aprovação
Despacha para aprovação
Aprova requisição
Estas atividades podem ser iniciadas ao mesmo tempo
Figura 79 – Uso de artefatos no BPD
8.2.4.1 Objeto de dados São mecanismos para mostrar que dados são requeridos ou produzidos pelas atividades. São conectados às atividades a partir das associações. BPMN BPMN
<> Grupos
Objetos de dados Anotações
Figura 80 – Artefatos do BPD
8.2.4.2 Grupo Um grupo pode ser usado para documentação, mas não afeta o fluxo de mensagens. 8.2.4.3 Anotação É um mecanismo para um modelador colocar textos de informações adicionais no diagrama.
132
Modelagem de Processos 8.3 Conclusão do BPMN
Um objetivo-chave da BPMN foi criar uma ponte entre a notação da modelagem de processos de negócios e a modelagem de linguagens orientadas para TI, que irá implementar os processos dentro de um sistema de gestão de processos de negócios. Observação Os objetos gráficos da BPMN, apoiados por um rico conjunto de atributos de objeto, foram mapeados para o Business Process Execution Language for Web Services (BPEL4WS v 1.1), o padrão de fato para a execução do processo. Resumo Esta unidade mostrou os conceitos envolvidos com a modelagem de negócios que precede a modelagem de sistemas de informação. Mostrou também que a UML propõe uma notação e um padrão de modelagem voltados para a especificação das regras de negócio de uma função e processo de negócio de uma organização. A OMG também vem propondo o uso da nova notação denominada BPMN, que está sendo preparada para novas ferramentas de automação de aplicações a partir dos modelos de negócio. O uso dessa combinação tem como grande objetivo colocar a área de desenvolvimento de sistemas totalmente casada com ás áreas de negócio e construindo aplicações que agreguem valor ao negócio. Com relação às organizações, elas estão descobrindo que a modelagem de processos de negócio pode ser uma excelente ferramenta para disseminar o conhecimento organizacional. Uma vez que as organizações passam a compreendê-lo como um recurso, a modelagem de processos de negócio pode tornar-se uma excelente fonte para a vantagem competitiva. Processos de negócio estruturados na cooperação, integração e no alinhamento entre todas as áreas organizacionais constituem o segredo de sucesso de uma organização. Atualmente, o modelo de caso de uso de negócio pode ser aplicado nos modelos de desenvolvimento em cascata, na fase de levantamento 133
Unidade IV de requisitos de negócio, e no modelo iterativo RUP, na fase de iniciação, também para modelagem dos requisitos de negócio que precedem as definições e especificações dos modelos dos sistemas de informação da organização. Exercícios Questão 1. Os autores definem que processos de negócio são um conjunto de atividades previamente estabelecidas cujo objetivo é determinar como o trabalho será realizado em uma organização por uma área de negócio. Diz-se que uma estrutura de processos de negócio mal concebida pode por em risco a eficiência e a eficácia da organização por meio dos produtos e serviços gerados e disponibilizados. Considerando os conceitos sobre processos de negócio, analise as afirmações a seguir e assinale a alternativa incorreta: A) Uma função de negócio é a mesma coisa que um processo de negócio, já que ambos representam o conjunto de atividades de uma organização. B) Processos de negócio são atividades transfuncionais previamente estabelecidas para tratar um determinado negócio da organização. C) Um sistema de informação bem estruturado implementa processos de negócio de uma empresa ou organização. D) Uma Função de Negócio representa a estrutura funcional da Organização, já que um “Processo de Negócio” é um conjunto de atividades ou ações que são transfuncionais, isto é, atravessam diversas áreas ou funções de negócio. E) Os processos de negócio devem funcionar de forma alinhada em relação a toda a estrutura organizacional, pois somente dessa forma será possível atingir os objetivos transversais de qualquer organização. Resposta: Alternativa A. Alguns autores definem processo de negócio ou processo organizacional como sendo um conjunto de atividades. Nesse conjunto, uma organização deve ser estruturada com o objetivo de produzir valor para os seus clientes. Análise das alternativas A) Incorreta. Função de negócio é uma representação de uma estrutura dentro de uma organização. Por exemplo: o departamento financeiro é uma função de negócio; já um sistema financeiro (processo de negócio financeiro), atua em diversas áreas da empresa. Quando se mapeia o processo de negócio financeiro, torna-se necessário entender diversas áreas ou 134
Modelagem de Processos funções da empresa, que, de alguma forma, utilizam ou precisam tratar com as informações financeiras da empresa. B) Correta. Os processos de negócio estão diretamente ligados aos negócios da empresa e independem da estrutura organizacional. Normalmente atravessam as fronteiras das funções de negócio. C) Correta. Um sistema de informação automatiza atividades dos processos de negócio, e, se ficarem estritamente ligados a uma função da empresa, não serão eficazes na busca de valor para a instituição. D) Correta. uma função de negócio representa uma estrutura funcional de uma empresa, por exemplo: área de TI, área de Logística etc. E um processo de negócio seria a venda de carros de luxo de uma montadora de veículos. E) Correta. A venda de carros de luxo de uma montadora possuirá atividades espalhadas por toda a estrutura de uma montadora: área de marketing, design de veículos, linha de produção, e assim por diante. Questão 2. Na atualidade, com propósito de se ter sistemas de informações abrangentes e que agreguem valor ao negócio de uma organização, evolue-se para duas visões complementares: a modelagem de negócio e a modelagem de sistemas de informação. Normalmente, as modelagens de negócio e de sistemas (software) são desenvolvidas como parte de dois diferentes projetos, com dois diferentes times. A modelagem de negócios trata todas as atividades envolvidas com o negócio, e a modelagem de sistemas verifica o aspecto de automação a partir do modelo de negócio. Ambas devem possuir boa definição, pois são ferramentas importantes para o gerenciamento da complexidade da amplitude e dificuldade do sistema. Considerando os conceitos sobre Arquitetura de negócio, Arquitetura de Software e exemplos apresentados nesta unidade, analise as afirmações a seguir e assinale a alternativa incorreta: A) Para a modelagem de negócio, utiliza-se a notação BPMN, a qual surgiu como um padrão alternativo à UML, já que esta foi desenvolvida para abranger somente as atividades de desenvolvimento de software. B) A modelagem de negócio com BPMN é gráfica, porém, para representar as atividades existentes nos processos de negócio, seus símbolos são um pouco diferentes da UML. C) Quem desenvolveu o BPMN foi o Instituto de Engenharia de Software, em 1991. D) Pode-se afirmar que o processo de modelagem de negócios “é um conjunto estruturado de atividades, desenhado para produzir um resultado específico para um cliente ou um mercado em particular”. E) A modelagem de negócio leva em consideração que um processo é “uma ordenação específica de atividades de trabalho, por meio do tempo e do espaço, com começo, fim e entradas e saídas claramente identificadas: é uma estrutura para ação”. Resolução desta questão na plataforma. 135
Figuras e ilustrações Figura 2
Estrutura de um modelo de AOO. Adaptada de YOURDON, E.; ARGILA, C. Análise e projeto orientados a objetos, São Paulo: Makron Books, 1998. Figura 3
Exemplo de uma aplicação da AOO. Adaptada de YOURDON, E.; ARGILA, C. Análise e projeto orientados a objetos, São Paulo: Makron Books, 1998. Figura 57
Processos de negócio. Disponível em: . Acesso em: 14 mai. 2012. Figura 59
Relacionamento de processos, Sistemas de Informação (SI) e Redes de Computadores (RC). PAUL, R. J.; SERRANO, A. Simulation for business processes and information systems design. Anais da Conferência de Simulação de Inverno de 2003. Departamento de Sistemas de Informação e Computação, Universidade de Brunel, U.K.: Uxbridge Middlesex, 2003. Figura 60
O relacionamento entre Engenharia de processo de negócio e Engenharia de software. RUP. Rational Unified Process. Rational Software Corporation, versão 2002.05.00, 2001. Figuras 61 e 62
Processo iterativo após o surgimento da modelagem de negócio e Modelagem de negócio como fase integrante do processo iterativo. BOGGS; BOGGS. Mastering UML with Rational Rose. SYBEX Sample Chapter. 2002. Figura 63
Integração entre modelagem de negócio e sistema. RODRIGUES, V. M. S. Mapeamento de processos de negócio com base nas extensões de penker e eriksson para casos de uso. Portugal. 2004. Figura 64
O esforço da modelagem de negócios e requisitos. RUP. Rational Unified Process. Rational Software Corporation, versão 2002.05.00, 2001. 136
Referências BRANCO, I. V. C. Modelagem de processos organizacionais integrada às aplicações práticas de aprendizagem organizacional e compeências conversacionais. Dissertação de Mestrado da UCB, Brasilia, Brasil, 2007. BOGGS; BOGGS. Mastering UML with Rational Rose. SYBEX Sample Chapter. 2002. BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML – guia do usuário. Rio de Janeiro: Editora Campus, 2000. COCKBURN, A. Escrevendo casos de uso eficazes – um guia prático para desenvolvedores de software. Tradução de Roberto Vedoato. 1ª ed. Porto Alegre: Bookman, 2005. DALAL, N. et al. Toward an integrated framework for modeling enterprise processes. Communications of the ACM, v. 47, nº 3, 2004. ERIKSON, H.; PENKER, M. Business modeling with UML: business patterns at work. John Wiley & Sons, 2000. HUCKVALE, T.; OULD, M. Process modeling: why, what and how., New York, EUA: Jonh Wiley, 1993. FURLAN, J. D. Modelagem de objetos através da UML, São Paulo: Makron Books, 1998. JACOBSON, I; BOOCH, G; RUMBAUGH, J. The unified software development process. Indianápolis, EUA: Addison Wesley, 1999. JACOBSON, I; BOOCH, G; RUMBAUGH, J. The unified modeling language – user guide. Massachusetts, EUA: Addison Wesley, 1999. LAUDON, K. C.; LAUDON, J. P. Gerenciamento de sistemas de informação. Rio de Janeiro: LTC, 2001. MEDEIROS, E. Desenvolvendo software com UML. São Paulo: Makron Books, 2004. OMG. Object management Group. Disponível em: . Acesso em: 17 ago. 2005. PAUL, R. J.; SERRANO, A. Simulation for business processes and information systems design. Anais da Conferência de Simulação de Inverno de 2003. Departamento de Sistemas de Informação e Computação, Universidade de Brunel, U.K.: Uxbridge Middlesex, 2003. PFLEEGER, S. L. Engenharia de software – teoria e prática. São Paulo: Prentice hall, 2004. RUMBAUGH, J. et al. Modelagem e projetos baseados em objetos. São Paulo: Editora Campus, 1994. REED JR., P. R. Desenvolvendo aplicativos com Visual Basic e UML. São Paulo: Makron Books, 2000. 137
RODRIGUES, V. M. S. Mapeamento de processos de negócio com base nas extensões de Penker e Eriksson para casos de uso. Portugal, 2004. RUP. Rational Unified Process. Rational Software Corporation, versão 2002.05.00, 2001. SENGE, P. M. A quinta disciplina: arte, teoria e prática da organização de aprendizagem. São Paulo: Best Seller, 1990. SZILAGYI, D. C. Modelagem de processos de negócio – um comparativo entre BPML e UML. Dissertação de Mestrado da Pontifícia Universidade Católica – São Paulo, 2010. YOURDON, E.; ARGILA, C. Análise e projeto orientados a objetos, São Paulo: Makron Books, 1998. WIDRIG, D.; LEFFINGWELL, D. Managing software requirements: a use case approach. 2ª ed. Addison Wesley, 2003.
138
139
140
141
142
143
144
Informações: www.sepi.unip.br ou 0800 010 9000
MODELAGEM DE PROCESSOS
UNIDADE IV Questão 2 Resposta correta: C. Justificativa A) Correta. Para a modelagem de negócio, é utilizada a notação BPMN, a qual surgiu como um padrão alternativo à UML. Os autores da UML eram da área de software e desenvolveram esse padrão para ser utilizado somente no desenvolvimento de sistemas. B) Correta. Tanto a modelagem de negócio como a modelagem de sistemas utilizam símbolos gráficos, porém a simbologia da modelagem de negócios está voltada para o entendimento das atividades do processo, enquanto a modelagem de sistemas está voltada para a solução das funcionalidades e arquiteturas de sistemas de informação (software). C) Incorreta. Quem desenvolveu o BPMN foi o Business Process Management Initiative (BPMI), iniciativa oriunda da OMG que lançou a especificação 1.0 ao público em maio de 2004. D) Correta. A técnica de Modelagem de Negócios é profundamente relacionada à Arquitetura de Negócios e é baseada em atividades das áreas de negócio. E) Correta. Processo de Negócio é definido como a sequência completa de um comportamento de negócio provocado por algum evento e que produz um resultado significativo para o negócio e que, de preferência, tenha foco no cliente.
