Unidade II MODELAGEM DE PROCESSOS

Transcrição

1 Unidade II 3 MODELAGEM DE SISTEMAS 1 20 A fase de desenvolvimento de um novo sistema de informação (Quadro 2) é um momento complexo que exige um significativo esforço no sentido de agregar recursos que venham a apoiar a geração do código, a validação e a implantação do que é o objetivo do evento de uma forma clara, eficiente e no tempo planejado. Os profissionais ligados ao desenvolvimento de sistemas usam dados, processos e modelos de objeto para compreender os sistemas existentes e projetar os novos. Esses modelos tornaram-se um padrão no mercado porque fornecem uma linguagem que os analistas, os projetistas e os desenvolvedores podem usar para comunicar-se eficientemente. Dessa forma, os gerentes de projetos se beneficiam da compreensão desses modelos, de modo que possam melhor comunicar suas necessidades. Atualmente, existem softwares que geram programas de computador diretamente dos modelos de sistema. São as chamadas ferramentas CASE (Computer-Aided Software Engineering, ou Engenharia de Software Assistida por Computador), que podem acelerar, de maneira significativa, o desenvolvimento de sistemas. Essas ferramentas podem auxiliar os desenvolvedores a compreender e a manter estes programas. 9

2 Unidade II 3.1 Os desenvolvedores de sistemas podem escolher entre quatro caminhos Modelo Descrição Usos Vantagens Desvantagens Segue ordenadamente os Projetos de grande porte Sem retrabalho. Altamente inflexível. estágios do ciclo de vida e complexos, com muitas Cascata do desenvolvimento de pessoas e áreas envolvidas sistemas. Fácil de administrar. Não há entregas provisórias. Espiral Entrega o sistema em versões conforme a regra 80/20, de acordo com a necessidade. Organizações dinâmicas que podem tolerar ambiguidades e necessitam obter resultados com rapidez. Rápida entrega do produto. Progresso fácil de ver Retrabalhos constantes Custos elevados. Concentra-se na interface do usuário numa interação cíclica dos estágios de projeto e desenvolvimento. Projetos de porte pequeno a médio, em que os requisitos são vagos ou obscuros. Curto período entre análise e implementação. O sistema satisfaz melhor as necessidades. Aumenta as expectativas do usuário. Não garante redução de custos. Prototipagem Evita custos desnecessários. Atrasa a funcionalidade do sistema. Ampliada comunicação e interação entre usuários e desenvolvedores. Programação ágil Avalia necessidades e desenvolve especificações durante o desenvolvimento. Pequenos projetos conduzidos por desenvolvedores experientes e competentes e usuários que desejam tomar parte no processo de desenvolvimento. Rápida entrega do produto Pronto atendimento às necessidades do usuário Mais difícil de aplicar conceitos de qualidade, tais como medição de desempenho e melhoria de processos. Pode decair acentuadamente com desenvolvedores fracos. Quadro 2 - Estilos de desenvolvimento de sistemas. Fonte: Gordon e Gordon, 2006.

3 3.2 Modelos de dados Os modelos de dados são responsáveis por descrever os relacionamentos existentes entre os elementos de dados que uma organização utiliza. O modelo conhecido como entidaderelacionamento ou diagrama ER é um dos modelos de dados mais usados (Figura 6). Contudo, existem também outros modelos. O ANSI (American National Standards Institute) suporta um padrão diferente, o modelo de dados conhecido por IDEF1X. Este modelo assemelha-se ao modelo entidade-relacionamento. Uma vantagem deste modelo está em se converter mais diretamente para uma implementação de banco de dados relacional. Os produto, tais como o Visible Analyst, da Visible Systems, e o System Architect, da Popkin Software, suportam ambos os modelos, bem como diversos outros. região nome-representante fone-representante representante-vendas 1 representa dados-representante 1 ID endereço M clientes contato fone-cliente nome-cliente Figura 6 - Diagrama ER: mostra o relacionamento entre representantes de vendas e seus clientes. Fonte: Gordon e Gordon, Modelos de processos Os modelos de processos dividem um processo em etapas, identificam como estas etapas se relacionam entre si e indicam quais saídas de um processo são entradas para outros. Os modelos de processos mais utilizados incluem diagramas de 11

4 Unidade II estrutura, quadros de funções e diagramas de fluxo de dados (DFDs). Os diagramas de estrutura demonstram o relacionamento entre os programas e subprogramas que compreenderão o sistema acabado. Na Figura 7, o diagrama de estrutura para um sistema de folha de evidencia o projeto modular do sistema, no qual a execução de uma determinada tarefa, como o cálculo do líquido, requer a terminação das tarefas abaixo, que compreendem o cálculo de impostos e cálculo de deduções. Ler entrada Processo da folha de 1.0 Gerar saída Ler registro mestre de empregado Ler cartão de ponto Gerar relatório de Gerar cheques de bruto 3.1 líquido 3.2 normal horas extras impostos Figura 7 - Diagrama de estrutura de um sistema de folha de. Divide os processos de folha de em três subprocessos.os subprocessos sofrem novas divisões. Fonte: Gordon e Gordon, O quadro de funções, ilustrado na Figura 8, implementa o modelo IDEF0 do ANSI, no qual cada quadro de função corresponde a uma caixa num diagrama de estrutura. As deduções 12

5 linhas entre as caixas mostram os relacionamentos entre as entradas e saídas dos procedimentos. Os documentos que suportam a metodologia IDEF0 mostram um único quadro de função juntamente com a divisão dessa caixa em suas subtarefas em cada página. Controles Entradas Função de manutenção Saídas Mecanismos Figura 8 - O quadro de funções IDEF0 mostra como um processo se conecta com outros processos. Fonte: Gordon e Gordon, Os diagramas de fluxo de dados (DFDs) - Figura 9 - são responsáveis por modelar o fluxo dos dados entre processos. Mas, eles não modelam a decomposição dos processos em subprocessos ou a ordem em que as tarefas são executadas para realizar um processo. Por exemplo, um arquivo de empregados mantém dados armazenados sobre a classe de do empregado, o nível de e as deduções. Dessa forma, os processos para determinar o bruto e calcular o líquido usam esses dados armazenados. 13

6 Unidade II Limite do sistema Empregados Catrão de ponto Calcula bruto Pagamento bruto Calcula deduções extras de impostos Classe de incidência Nível de Arquivo de empregado Pagamento de deduções Cheque de Cria contracheque Condição de imposto Calcula impostos Pagamento líquido Pagamento líquido Saldo da tesouraria Registro histórico de s Tabelas de impostos Figura 9 - Diagrama de fluxo de dados de um sistema de folha de. São mostradas as entradas e saídas de cada procedimento e as fontes e o uso de dados que estão fora do limite do sistema. Fonte: Gordon e Gordon, Modelos de objeto Os modelos de objeto identificam as propriedades dos objetos, seus relacionamentos entre si e as funções que executam. Os modelos de objeto incluem, frequentemente, os diagramas de herança, que mostram como os objetos herdam suas propriedades de outros objetos. Os modelos de objeto podem também incluir diagramas de estado para mostrar como as características de objeto mudam à medida que os eventos externos afetam um objeto, e como o objeto responde diferentemente às mensagens, dependendo do seu estado. 14

7 1 20 Os objetos incorporam tanto os dados quanto as operações que podem ser executadas sobre os dados. Os relacionamentos entre objetos, dados e processos motivaram o desenvolvimento de modelos que incorporam todos os três elementos. Entre os recursos mais populares para se gerar modelos que estabeleçam os relacionamentos desejados está o UML. Porém, deve-se refletir a respeito sobre o que é realmente desenvolver sistemas orientados a objetos. Ao se observar a forma como a análise e o projeto de sistemas vem sendo realizada em muitos lugares, pode-se verificar que muitos profissionais simplesmente adotam uma linguagem orientada a objetos ou até algum fragmento de processo orientado a objetos, sem muita consciência do que estão fazendo. Portanto, de nada adianta realizar investimentos pesados na aquisição de ferramentas CASE orientadas a objetos sem a devida compreensão da forma de se pensar orientada a objetos. Dessa forma, conclui-se que o uso de diagramas pode não melhorar a qualidade do software produzido. Para um profissional chegar a ser um arquiteto de software, existe uma série de conhecimentos que precisam ser compreendidos UML Muitos profissionais acreditam que UML é uma metodologia, mas na verdade é uma linguagem. UML significa Unified Modeling Language (linguagem de modelagem unificada) e é usada para descrever eventos. Contudo, conhecer uma linguagem não implica em habilidade para saber utilizá-la com efeito. Tome-se por base a língua portuguesa ou a inglesa, nas quais saber escrever não necessariamente implica em saber falar bem, ou descrever eventos com precisão para que qualquer leitor possa compreender. Nesse caso, existem métodos ou processos que auxiliam, por exemplo, os escritores na definição de eventos com clareza. Esses métodos e processos ajudam a estruturar adequadamente as frases para que estas produzam o efeito desejado. 1

8 Unidade II Dessa forma, ao se usar a linguagem UML, pretende-se produzir projetos de sistemas com elegância, claros e bem estruturados, nos quais os leitores terão uma fácil assimilação do que se pretende descrever. 4.1 Para que é utilizado a UML? 1 A UML é uma das mais linguagens mais utilizadas no mundo para especificar modelos de sistemas. Foi desenvolvido pelo OMG (Object Management Group), e destina-se a modelar aplicações, comportamentos, arquitetura e também processos de negócios e estruturas de dados. Além disso, promove a unificação de vários passos do desenvolvimento e da integração de modelos de negócios por meio da modelagem de arquitetura e aplicação para o desenvolvimento, implantação, manutenção e evolução. O OMG é formado por um consórcio da indústria da computação, sem fins lucrativos, que desenvolve uma força tarefa para definir padrões de integração para as corporações para um amplo escopo de tecnologias. Segundo a OMG, a UML é uma linguagem visual para especificação, construção e documentação de artefatos de software: 20 a criação de esquemas UML, cujo o propósito da modelagem é, principalmente, para entender e documentar; 2 a UML sozinha não resolve nada: ela deve ser usada dentro de um processo de desenvolvimento! A UML define uma linguagem padrão e uma notação gráfica para a criação de modelos de negócios e sistemas técnicos. Ao contrário da opinião popular, a UML não é apenas para programadores. De fato, a UML define diversos tipos de modelos que abrangem uma grande escala de modelos e requisitos funcionais de fluxo de trabalho para projetos de estrutura de 16

9 classe e diagramas de componentes. Este livro descreve como esses modelos são aplicados para especificar o uso da XML no contexto de um sistema de e-business. Esses modelos, e um processo de desenvolvimento que os utiliza, melhoram e simplificam a comunicação entre interessados de aplicações muito diversas. 1 A UML tem progredido a passos largos para atingir seu objetivo de possuir um padrão unificado e está se tornando a linguagem preferida para a descrição de sistemas de negócios. O fato de a UML ter sido aceita na prática, e não apenas como um padrão teórico formal, contribuiu para um rápido desenvolvimento e para uma competição saudável entre as ferramentas de modelagem UML. Os produtos compatíveis com UML abrangem desde conjuntos de engenharia de software completos até ferramentas de análise de requisitos orientadas a negócios relativamente baratas. 17