Definir o espaço das informações das organizações; Realizar o detalhamento das análises dos fluxos de dados;

MODELAGEM DE SISTEMAS DE INFORMAÇÃO EAD Módulo 1 Arquitetura dos sistemas de informação A unificação das perspectivas desenvolvidas pelo modelo de negócio e dos sistemas de informação formam a arquitetura dos sistemas de informação. O modelo de negócios permite a discussão e compreensão auxiliando na definição das atividades que são executadas com o intuito de atingir os objetivos de uma organização. A modelagem de negócios é fundamental para a especificação dos sistemas de informação com suporte aos modelos de negócios. 1.1 arquitetura da informação O termo arquitetura da informação é utilizado como uma metáfora pelos especialistas que projetam os sistemas de informação para indicar um modelo de organização abrangente e que serve para a geração e movimentação dos dados. Seus modelos e metodologias baseiam-se em documentar todas as fontes de dados importantes dentro de uma organização. Ex: Clientes; Funcionários; Produtos. O desenvolvimento bem definido de uma arquitetura de informação pode estabelecer um acordo em comum entre as informações, de forma que as partes envolvidas utilizam a informação para a tomada de decisões. Logo, sua tarefa é a organização das informações dentro de um ambiente. Objetivos da arquitetura de informações: Definir o espaço das informações das organizações; Realizar o detalhamento das análises dos fluxos de dados; Definir os limites críticos do espaço das informações das organizações; Determinar o que é informação e de onde ela vem; Filtrar as informações. 1.2 Arquitetura dos sistemas de informação A arquitetura dos sistemas de informação representa a estrutura dos componentes de um sistema, seus princípios, relações e diretrizes que conduzem a sua construção e evolução ao longo do tempo. Segundo (Zachman, 1997) a arquitetura é um conjunto de representações que são necessárias para a descrição de um sistema, visando a sua construção, manutenção e evolução. Com isso, chegamos à conclusão que a arquitetura

dos sistemas de informação é importante tanto no seu projeto, modelagem, desenvolvimento e ao longo de toda a sua vida. Como objetivo de representar a estrutura dos componentes dos sistemas de informação, suas relações, princípios e diretrizes. A arquitetura dos sistemas de informação apresenta o modo como os componentes são internamente construídos e conectados, definindo as classes e objetivos fundamentais para a sua implementação, mas deixando para segundo plano as relações existentes entre os negócios. Se observarmos, a arquitetura dos sistemas de informação é considerada um fator determinante no sucesso das organizações, e para alguns executivos, alguns fatores os preocupam, como: Capacidade de adaptação dos sistemas de informação as necessidades de negócios; Acesso aos dados no formato adequado no momento e local necessário; Dados consistentes e corretos; Compartilhamento de informações pela organização; Controle de custos a nível de sistemas de informação. Para resolver todos esses problemas, deve ser feita uma boa especificação da arquitetura, e com isso obter os seguintes benefícios: Redução da complexidade; Assegurar a construção de sistemas duráveis, flexíveis e que se adaptem as necessidades dos negócios; Permitir a integração e o compartilhamento dos dados em toda a organização; Alinhar os componentes tanto da tecnologia da informação como dos sistemas de informação; Evolução e introdução de novas tecnologias; Atender às necessidades dos clientes; Maior eficiência no uso da tecnologia da informação. Uma boa arquitetura permite a obtenção do balanceamento correto entre a inovação, tecnologia eficiente e as necessidades exigidas. No entanto, a definição de uma arquitetura não fornece qualquer garantia de alinhamento entre a tecnologia e o negócio.

1.3 Arquitetura dos sistemas 1.3.1 Sistemas centralizados Os sistemas centralizados são executados sobre um único sistema operacional, não existindo interação com outros sistemas. Esses sistemas podem estar localizados em um computador pessoal, onde são acessados por um único usuário ou localizados em um sistema de alto desempenho como os mainframes. 1.3.2 Sistemas clientes/servidores Nos sistemas clientes/servidores, os computadores clientes (front-end) processam as aplicações enquanto os servidores (back-end) fornecem os serviços aos clientes. Funções de clientes e servidores: Funções do cliente: Gerenciar a interface do usuário; Processar a lógica da aplicação; Impor regras de negócios; Gerar solicitações; Receber os resultados que são enviados pelo servidor; Formatar os resultados recebidos. Funções do servidor Aceitar as solicitações enviadas pelos clientes; Processar as solicitações; Formatar os resultados e transmiti-los aos clientes; Impor regras de negócios; Realizar verificação de integridade; Fornecer o controle de acesso; Fornecer serviços de segurança.

Na arquitetura cliente/servidor o programa de aplicação é instalado na máquina cliente, e o aplicativo existente na máquina servidora é responsável pelo recebimento das solicitações de processamento da aplicação. A arquitetura dos sistemas de informação tem um papel preponderante no alinhamento entre as realidades dos negócios, da tecnologia da informação e sistemas de informação de uma organização. Módulo 2 Modelo de Informações Organizacionais e Decisórios O modelo de informações organizacionais é de vital importância para as organizações, no planejamento, desenvolvimento ou aquisição de sistemas de informação. Sem a elaboração desse documento, algumas organizações estão enfrentando prejuízos financeiros e pessoais, principalmente quando desejam a aquisição de um sistema de informação ou o seu desenvolvimento. Como falamos anteriormente, os níveis de decisão organizacional obedecem a uma hierarquia que é padrão na maioria das organizações. O tipo de decisão que é tomado em cada nível requer diferentes graus de agregação de informações. Para tomar essas decisões são necessárias informações sobre seus diversos tipos de produtos, onde essas informações podem ser apresentadas por meio de relatórios, telas, etc. O modelo de informações organizacionais descreve todas as informações necessárias para a gestão de atividades e negócios, essas informações devem atender a todos os requisitos funcionais, requeridos de um ou mais sistemas de informação. Tem como principal objetivo auxiliar a organização na aquisição de sistemas de informação, e contribuir para o processo de desenvolvimento ou manutenção de um projeto de sistemas de informação. Essas informações estruturam-se em níveis de informação, sendo: estratégicas, gerenciais e operacionais. As informações podem estar distribuídas em diversas funções organizacionais, tais como: Comercial, logística, financeira, RH, jurídico, etc. Além disso, podem ser desmembradas e divididas em subsistemas. Para a elaboração dessa atividade nas organizações, um documento em forma de tabela pode ser elaborado, onde são descritos apenas as informações e em outro, procedimentos de como construir informações necessárias. Abaixo, temos um exemplo de um modelo de documento de informações organizacionais: Função: Financeira Nível de Informação Estratégico Gerencial Módulo: Contas a Receber - Valor total de contas a receber X valor total de contas a pagar; - Percentual do valor de contas a receber X valor do fluxo de caixa. - Valor total de contas a receber;

Operacional - Quantidade de títulos pagos; - Quantidade de inadimplentes. - Nome do cliente; - Valor do título; - Data de vencimento; - Data de pagamento; - Nome do banco; É importante ressaltar que as informações devem-se integrar nos níveis, ou seja, para se obter informações gerenciais e estratégicas, é necessária a existência das informações operacionais. As informações existentes no modelo de informações organizacionais podem conter informações que estão integradas dos seguintes tipos: convencional, personalizadas e oportunas. As informações personalizadas e oportunas facilitam o mapeamento do conhecimento organizacional, sendo também chamadas de informações inteligentes. Módulo 3 - Modelos Decisórios O modelo decisório contribui para o processo de tomada de decisão, tanto na ordem tática como na ordem estratégica. Eles buscam fornecer informações e conhecimentos inteligentes, adequando-se às situações peculiares de cada organização. Esses modelos estão interligados aos sistemas de informação, e as organizações necessitam deles, pois com o seu auxílio, os gestores podem analisar os dados dos meios internos e externos, visando propor soluções importantes. Vamos analisar agora, alguns tipos de modelos decisórios existentes, e observar suas particularidades. 3.1 Modelo convencional O modelo convencional trata os dados para serem transformados em informações e conseqüentemente em conhecimento, com isso, alguns gestores podem tomar decisões de ordem mental ou executar ações de ordem física. Essas ações geram resultados que podem ser positivos ou negativos, existindo sempre uma retroalimentação do ciclo decisório.

Essa alimentação faz-se necessária por causa das mudanças internas e externas no ambiente. Como exemplo de mudanças, temos os clientes, fornecedores, movimentação bancária, etc. Esse modelo decisório é mais indicado para decisões triviais e rotineiras, que não geram grandes impactos futuros. 3.2 Modelo Dinâmico Como nem sempre o modelo convencional atende completamente as necessidades das organizações, o modelo dinâmico foi apresentado com o intuito de fornecer informações para as organizações, e não o tratamento de dados como é feito no modelo convencional. As organizações nos dias de hoje devem ser dinâmicas, o mercado e a sociedade exigem esse dinamismo, com isso, a tomada de decisões complexas é feita a todo o momento no processo de gestão, e diferentemente da produção, a gestão não é repetitiva e nem estruturada. Essas decisões nem sempre são fáceis de serem tomadas, pois podem contribuir a favor ou contrário ao resultado final do processo, acabando por prejudicá-los. Algumas dificuldades podem ser encontradas em três fases do processo decisório, são elas: Fase de investigação: Dificuldades em identificar, categorizar e definir o problema. Fase de concepção: Dificuldade em gerar, avaliar e descrever alternativas para o desempenho. Fase de escolha da decisão: Dificuldade em identificar métodos de seleção, organizar e apresentar a informação.

Por causa de todas as dificuldades apontadas, faz-se necessário que as organizações apresentem modelos dinâmicos, pois nem sempre os dados que estão armazenados são necessários para gerar informações e conhecimentos requeridos. O maior desafio para implementar o modelo decisório dinâmico é a criação, modelagem e estruturação das informações, pois ela são muito importantes para a gestão das organizações que as utilizam. Módulo 4 ENGENHARIA DE SISTEMAS Como conseqüência do crescimento e da necessidade de desenvolver grandes sistemas de informação, para a substituição dos pequenos programas que eram utilizados em separado dentro das empresas, surgiu um grande problema, que era a falta de experiência e de métodos para o desenvolvimento desses grandes sistemas. Toda essa dificuldade permitiu o nascimento da engenharia de sistemas. O custo para o desenvolvimento de grandes sistemas corresponde a uma percentagem cada vez maior nos gastos das empresas, pois a tecnologia de desenvolvimento de sistemas implica cada vez mais em uma grande carga de trabalho, envolvendo um grande número de pessoas e um prazo relativamente logo para o seu desenvolvimento. Esse desenvolvimento é realizado na maioria das vezes de forma ad-hoc, não respeitando os cronogramas que foram traçados e acrescendo assim custos ao desenvolvimento. De uma forma clássica podemos também definir esses sistemas como um conjunto de instruções, componentes e partes que quando executados,

produzem funções e desempenhos que são desejados. A estrutura dos seus dados permite que as informações relativas ao problema a ser resolvido, sejam manipuladas adequadamente. Um sistema é sistematicamente destinado a ser utilizado por usuários que podem ter formações diferentes, sendo necessária a preocupação no desenvolvimento, para que o produto tenha uma interface amigável e uma documentação rica em informações, o que possibilita o conhecimento e exploração de todos os recursos que o sistema oferece de forma eficiente. Todos esses sistemas devem ser submetidos a uma grande série de testes, pois é inviável que os usuários tenham que detectar e corrigir os erros encontrados. Para caracterizar melhor o significado da engenharia de um sistema, algumas particularidades devem ser observadas: Um sistema é desenvolvido como resultado de um trabalho de engenharia e não manufaturado no sentido clássico; Um sistema não se desgasta como a maioria dos produtos, pois não se caracteriza por um aumento na possibilidade de falhas a medida que o tempo passa. Em função das características citadas, o processo de desenvolvimento de sistemas pode gerar um conjunto de problemas que terão influência direta na qualidade do produto final. Em nível de grande porte, algumas questões que caracterizam as preocupações com o desenvolvimento de sistemas são: Por que os sistemas demoram tanto para serem construídos? Por que o custo para a construção de um sistema é tão elevado? Por que é tão complicado detectar todos os erros que o sistema possui antes de ser entregue ao cliente? Por que é tão difícil fazer uma medição de progresso no desenvolvimento do sistema? Essas são algumas questões que a engenharia de sistemas pode auxiliar para que sejam resolvidas. Vamos citar alguns pontos que causam os problemas que citamos acima: Durante o desenvolvimento do sistema, raramente é dedicado um tempo para que seja feito uma coleta de dados sobre o processo de desenvolvimento em si. A pouca quantidade desse tipo de informação, e as tentativas utilizadas para se estimar a duração e os custos para a produção têm conduzido na geração de resultados insatisfatórios.

Ocorre freqüentemente o questionamento de clientes insatisfeitos com os sistemas, pois grande parte desse desenvolvimento é feita através de informações vagas sobre as necessidades e desejos dos clientes. A qualidade do sistema desenvolvido é suspeita, pois pouca atenção foi dada e não foram utilizadas técnicas de teste e conceitos de qualidade de software. O sistema existente é normalmente difícil de manter em operação, pois grandes custos são alocados para atividades relacionadas à manutenção, sendo reflexo da pouca importância que foi dada na manutenção do sistema no momento da sua concepção. Como causa dos problemas citados acima, podemos citar alguns pontos: Falta de experiência dos profissionais que estão conduzindo o projeto; Falta de treinamento em técnicas e métodos de desenvolvimento de softwares; A resistência a mudanças que os profissionais antigos apresentam as novas técnicas de desenvolvimento de sistemas. É preciso está ciente que não existe uma abordagem padrão que seja a solução para todos os problemas citados, mas uma combinação de métodos que sejam abrangentes a todas as etapas do desenvolvimento de um sistema. Todos esses métodos devem ser suportados por um conjunto de ferramentas que permita a automatização dessas etapas, e junto com essas ferramentas é necessária a definição clara dos critérios de qualidade a serem aplicados. Módulo 5 - Modelos de desenvolvimento O processo de desenvolvimento corresponde a um conjunto de atividades ordenadas de modo que o produto desejado seja obtido. O modelo de desenvolvimento é uma representação abstrata do processo de desenvolvimento que vai definir como as etapas relativas ao desenvolvimento do sistema serão direcionadas e relacionadas para que possam atingir o objetivo desejado, que é obtenção de um produto de alta qualidade. Podemos organizar o processo de desenvolvimento em três grandes fases: Definição: está associada ao que vai ser feito. Nesta fase devem ser identificadas as informações que serão manipuladas. Na fase de definição, são caracterizadas três etapas específicas: Análise do sistema Planejamento do projeto do sistema Análise dos requisitos

Desenvolvimento: será determinado como realizar as funções do sistema, envolvendo a sua arquitetura, estrutura dos dados, procedimento e a utilização das linguagens de programação. Na fase de desenvolvimento, são caracterizadas três etapas específicas: Projeto do sistema Codificação Teste Manutenção: a manutenção é iniciada a partir do momento em que o sistema é entregue ao cliente. São realizadas alterações de diversos tipos, seja a correção de erros, inclusão de novas funções ou adaptação de novas configurações. Nesta fase, caracterizamos as seguintes atividades: Correção Adaptação Melhoramento Funcional Considerando a situação atual do mercado, foi criado o conceito de engenharia reversa, que utiliza técnicas e ferramentas da engenharia de software para que o sistema existente sofra uma reforma geral com objetivo de aumentar a sua qualidade e atualizá-lo com respeito às novas tecnologias. Módulo 6 Análise Essencial O modelo de análise essencial apresenta o sistema em um grau de abstração completamente independente de restrições tecnológicas. Ele descreve quais os requisitos que um sistema deve atender sem se preocupar como poderá ou será implementado.

O modelo essencial é formado por: Modelo Ambiental: Define as fronteiras entre o sistema e o resto do mundo. Modelo Comportamental: Define o comportamento das partes internas e externas que são necessárias para interagir com o sistema. Análise Essencial Modelo Essencial Modelo de Implementação Modelo Ambiental Modelo Comportamental

O modelo de implementação apresenta o sistema em um grau de abstração completamente dependente das restrições tecnológicas. É uma derivação do modelo essencial e diz respeito à implementação do sistema. O Modelo Ambiental O modelo ambiental define as fronteiras do sistema com o ambiente onde ele se situa, determinando o que é interno e o que é externo. As interfaces entre o sistema e o ambiente externo determinam as informações que chegam ao sistema, vindas do mundo exterior e vice-versa. No modelo ambiental também é determinado os eventos oriundos do ambiente externo que o sistema deve responder. Ferramentas para definição do ambiente Declaração dos objetivos: Consiste em uma breve e concisa declaração dos objetivos do sistema, sendo dirigida pela alta gerência, gerência usuária ou outras pessoas que não estão envolvidas diretamente no desenvolvimento do sistema. Esse documento não pretender dar uma declaração detalhada do sistema, podendo ter uma ou várias sentenças, só que não deve ultrapassar um parágrafo. Exemplo: O objetivo do sistema da locadora XYZ é manusear todos os detalhes dos pedidos de aluguel de DVD`s feito pelos clientes, bem como reservar, faturar e cobrar dos clientes que estão em atraso. As informações sobre os pedidos de DVD`s devem ficar disponíveis para o sistema de: Marketing, Compras e Contabilidade. Diagrama de Contexto: O diagrama de contexto apresenta uma visão das características importantes do sistema, tais como: Pessoas, organizações e sistemas com os quais o sistema pode se comunicar; Os dados que o sistema recebe do mundo exterior e que devem ser processados; Os dados que são produzidos pelo sistema e são enviados para o mundo exterior; As fronteiras existentes entre o sistema e o resto do mundo.

Lista de Eventos: A lista de eventos é formada por estímulos que ocorrem no mundo exterior e implicam em algum tipo de resposta pelo sistema. Esses estímulos são ativadores de funções e a forma como os eventos agem sobre o sistema. As respostas são os resultados gerados pelo sistema, sendo sempre resultado da execução de alguma função interna. Tipos de Eventos: Orientado a Fluxo Temporal Temporal Relativo Modelo Comportamental O modelo comportamental define o comportamento interno que o sistema deve ter para se relacionar adequadamente com o ambiente. São definidos pontos de vista internos e o modelo interior do sistema, além disso, são descritas a maneira que os conjuntos de elementos inter-relacionados devem reagir internamente aos estímulos exteriores. O modelo comportamental é formado por: Diagrama de fluxo de dados; Mini-especificação; Diagrama de transição de estado; Diagrama de entidade relacionamento.

Modelo de Implementação O modelo de implementação tem por finalidade produzir um modelo para a implementação do sistema a partir de suas especificações conceituais e dos requisitos estabelecidos. São envolvidas questões relativas a utilização do sistema pelo usuário. Atividades necessárias para a construção do modelo: Construir modelo lógico dos dados; Determinar as características de processamento de cada função; Especificar a integração entre homem-máquina. A qualidade de um sistema está vinculada a certas características que são fundamentais e devem ser perseguidas como objetivo básico no projeto de um sistema. São elas: Alterabilidade Eficiência Segurança e controle Reusabilidade Portabilidade Estruturação do Sistema A estruturação do sistema consiste na obtenção de uma visão planificada dos processos primitivos do modelo comportamental, onde os processos são separados por características de processamento. Planificação: A planificação deve começar pelo diagrama de fluxo de dados de primeiro nível, e os passos abaixo devem ser executados até restar somente os processos primitivos. As vezes é inviável planificar todo o modelo comportamental de uma só vez, com isso, podemos fazer a planificação de cada processo do DFD no primeiro nível, e se existir um fluxo que os ligam diretamente, é feita uma planificação em conjunto. Empacotamento: O empacotamento consiste no agrupamento, separação, reagrupamento e segmentação dos processos primitivos do modelo funcional, construindo as unidades que serão implementadas. O resultado Diagrama de estrutura do sistema; Quadro de referência Processo X Programa; Fronteiras de processamento; Critérios para o agrupamento dos processos;

Critérios para a separação dos processos; Módulo 7 Análise Estruturada As dificuldades que são causadas por problemas de comunicação, mudanças de requisitos e técnicas inadequadas de avaliação, tornam a análise estruturada uma fase critica no desenvolvimento de sistemas. A definição de requisitos de uma forma precisa não é fácil e além dessas dificuldades, a linguagem do usuário e a linguagem do responsável pelo desenvolvimento são tão diferentes que uma comunicação eficaz é praticamente impossível. O principal objetivo da análise estruturada é resolver todos essas dificuldades, fornecendo uma abordagem sistemática para analisar e desenvolver especificação de sistema nova e melhorada. Esses objetivos são alcançados centralizando a análise em uma comunicação clara e concisa. A análise estruturada de sistemas é composta por um conjunto de técnicas e ferramentas que estão em constante evolução. Tem como conceito fundamental a construção de um modelo lógico de um sistema, utilizando técnicas que são capazes de construir uma estrutura geral do sistema, e como suas partes irão interagir para que seja possível atender às necessidades. 7.1 - Vantagens de desvantagens da análise estruturada: Vantagens O usuário adquire uma visão clara do sistema que é proposto pelo diagrama de fluxo de dados, essa visão é melhor do que as obtidas através de narrativas e fluxogramas de sistema físico. A apresentação através de fluxos lógicos consegue mostrar mal entendidos e pontos que são controversos. As interfaces entre o novo sistema e o já existente são mostradas de modo bem mais claro. Desvantagens O grau de detalhamento necessário, principalmente na construção do dicionário de dados. Orientação dos usuários e treinamento dos analistas é necessário, pois as regras do jogo são mudadas com a introdução da análise estruturada. 7.2 - Diagrama de fluxo de dados DFD

O DFD é uma representação dos processos de um sistema e dos dados que ligam esses processos. Ele é capaz de mostrar o que o sistema faz, mas não como é feito. O DFD é considerado a principal ferramenta de modelagem da análise estruturada, sendo utilizado para dividir o sistema em uma hierarquia de processos. O DFD possui quatro símbolos que permitem a construção do quadro do sistema sem o comprometimento com a implementação. Os símbolos e os conceitos que eles representam encontram-se no nível lógico. 7.2.1 - Técnicas de análise estruturada de sistemas Como foi comentado anteriormente, além das ferramentas, a análise estruturada é formada por técnicas de construção gráfica de modelos lógicos, para sistemas de informação gerenciais. Com isso, usuários e analistas encontraram uma solução clara para que sejam transmitidas as necessidades e soluções. É apresentado um desenvolvimento que começa com o diagrama geral do fluxo de informações, e depois é feito um refinamento sucessivo através da construção de fluxos compostos por informações mais detalhadas. Com isso, é permitido definir o quê o sistema deve fazer, tornando-se muito valioso no momento de determinar as entradas do sistema, ficando ele bem mais flexível. Fatores Externos Os fatores externos são compostos por atividades ou pessoas que interagem com o sistema, sendo a fonte ou o destino das informações. Ex: Clientes, fornecedores, bancos etc. Outros sistemas que fornecem dados ou informações, podem ser considerados fatores externos.

Com o intuito de evitar várias vezes o cruzamento do fluxo de informações, os fatores podem ser repetidos no mesmo fluxo, sendo representado pela simbologia abaixo. Fluxo de informações O fluxo de informações representa no diagrama uma canalização por onde as informações fluem, sendo representado por uma flecha que é direcionada no sentido do fluxo das informações. A flecha também pode ser direcionada nos dois sentidos em determinadas ocasiões. É interessante observar que por um mesmo fluxo podem fluir vários tipos de dados, mais não necessariamente esses dados vão fluir todos ao mesmo tempo. Processos Os processos são as atividades realizadas no sistema. Sua representação gráfica é a seguinte: Identificação: É um número que é atribuído ao processo para identificá-lo.

Descrição: É uma frase precisa formada por um verbo seguido de um objeto. Ex: Remete cobrança atrasada Localização física: Nome da unidade organizacional responsável pela atividade. Banco de informações O banco de informações é onde são gravados os dados e as informações, são representados graficamente por um par de linhas paralelas, sendo elas fechadas em um dos lados por outras linhas, formando um quadrado do lado esquerdo. Esse quadrado é utilizado para colocar a referência numérica para o depósito, sendo antecedido pela letra D, e no restante é colocado o nome atribuído no banco de informações. 7.3 Críticas a análise estruturada Existem várias técnicas estruturadas avançadas disponíveis para a fase de codificação do desenvolvimento, enquanto na análise as técnicas utilizadas são menos avançadas. Com isso a análise estruturada torna-se uma metodologia inicial e informal. Uma das melhorias que seria necessário implantar na análise estruturada, seria tornar um sistema de grande porte, que com sua utilização é quase ilegível em um gráfico de uso fácil e legível. Os defensores da análise estruturada consideram as especificações estruturadas como um elo entre a análise e o projeto, sendo o DFD utilizado como base para a construção de um projeto estruturado, e finalmente um sistema estruturado.

7.4 Onde utilizar a análise estruturada A análise estruturada deve ser utilizada apenas em problemas pequenos e simples, sendo o DFD a sua parte mais importante. Para sistemas maiores e mais complexos, o DFD pode ser utilizado apenas para esboçar uma visão de alto nível do sistema. Devem ser utilizados outros métodos mais rigorosos de análise para desenvolver uma especificação mais precisa. Módulo 8 Análise Orientada a Objeto É interessante observar como a análise orientada a objeto utiliza conceitos que aprendemos há muito tempo: objetos, atributos, classes, membros, todos e partes. Só não podemos explicar por que demorou tanto tempo para aplicar esses conceitos na análise e especificações dos sistemas de informação. O principal produto de uma equipe de desenvolvimento é um software que é capaz de atender a todas as necessidades dos usuários. Para que um software satisfaça os propósitos pretendidos, é necessária uma interação com os usuários de forma organizada, e com isso expor os requisitos reais do sistema. Esse software só terá uma qualidade de longa duração se a sua arquitetura aceitar modificações.

8.1 Modelagem A modelagem é tida como a parte central de todas as atividades para a construção de um bom sistema, com ela podemos: Construir modelos que comunicam a estrutura e o comportamento do sistema; Construir modelos que visualizam e controlam a arquitetura do sistema; Construir modelos que gerenciam os riscos; Construir modelos que propiciam a simplificação e reaproveitamento de sistemas. Segundo James Rumbaugh A modelagem baseada em objeto é tida como um novo modo de estudar problemas com a utilização de modelos que são fundamentados em conceitos do mundo real. A estrutura básica é o objeto, que combina a estrutura e o comportamento dos dados em uma única entidade. Os modelos baseados em objeto são úteis para a compreensão de problemas, para a comunicação com os peritos em aplicações, para modelar empresas, preparar documentações e projetar programas e bases de dados. No próximo módulo falaremos mais sobre modelagem de sistemas utilizando orientação a objeto e UML.

8.2 Principais vantagens da orientação a objeto: Melhor entendimento do problema a ser resolvido; Maior flexibilidade entre os blocos independentes que são produzidos; Boa divisão do trabalho entre diferentes equipes de desenvolvimento; Melhor participação dos usuários no processo de desenvolvimento do sistema; Ajuda a trabalhar com aplicativos complexos. 8.3 Principais problemas encontrados na orientação a objeto: Exige uma melhor concentração na análise e no projeto do sistema; Mudança na cultura de desenvolvimento; Os benefícios são evidenciados a longo prazo. 8.4 Conceitos de Orientação a Objeto Os conceitos básicos de orientação a objeto permitem a definição de: 8.4.1 Classes Segundo yourdon classe é uma descrição de um ou mais objetos com conjunto uniforme de atributos e serviços, incluindo uma descrição de como criar novos objetos na classe. A classe é a construção mais importante na orientação a objeto, onde cada classe pode conter: Nome Atributo Métodos e objetos. Nome: O nome de uma classe é obrigatório, e é utilizado para identificá-la diante das outras classes. Os nomes das classes são substantivos ou expressões breves, definidos a partir do vocabulário do sistema.

Atributo: Os atributos são propriedades nomeadas de uma classe que descrevem um intervalo de valores que as instancias podem apresentar, sendo ele uma abstração do tipo de dado ou do estado que os objetos podem abranger. Métodos: O método é a implementação de um serviço que pode ser solicitado, sendo uma abstração de algo que pode ser feito com um objeto, e é compartilhado por todos os objetos dentro da classe. O método pode expressar o comportamento que um objeto pode apresentar. 8.4.2 Objetos Um objeto pode ser um lugar, evento, coisa, relatório ou conceito que possa ser aplicado ao sistema, sendo uma abstração, algo que possui um limite nítido e simplificado em relação ao problema. O objeto facilita a compreensão do mundo real, e oferece a base para a implementação do mundo real no computador. Módulo 9 Análise Orientada a Objeto 9.4.3 Herança A herança mostra a igualdade entre as classes, podendo ser feita a simplificação da definição de classes iguais a outras que já foram definidas.

Com isso é possível representar a generalização e especialização, tornando visíveis os atributos e serviços que são comuns em uma hierarquia de classes. A herança pode ser entendida como um relacionamento entre uma superclasse (classe mãe), e um tipo mais específico chamado de sub-classe (classe filha). A classe filha herda as características da mãe e pode adicionar novas estruturas ou comportamentos. Exemplos de herança: Simples: Uma classe herda as características apenas de uma classe mãe; Composta: Uma classe herda as características de mais de uma classe mãe. 9.4.4 Associações As associações são relacionamentos fracos entre os objetos. Na UML, uma associação pode ser representada como uma linha que liga uma classe a outra.

9.4.5 Agregação A agregação representa um tipo de relacionamento do tipo tem um, significando que o objeto do todo contém os objetos das partes. Algumas vezes um objeto é constituído por outros objetos. 9.4.6 Composição É um caso particular de agregação, utilizado principalmente onde se evidencia uma forte conotação de propriedade. Também especifica que o objeto tem um ciclo de vida, e quando ele é destruído, as partes também são. 9.4.6 Encapsulamento Através do encapsulamento, podemos ocultar detalhes que são referentes a implementação do objeto, protegendo os dados conta adulteração, pois eles só podem ser acessados pelo próprio objeto, através dos seus métodos. 9.4.7 Métodos

Os métodos são as operações de uma classe. Eles são formados por interfaces que descrevem as características externas do método e pela implementação, que contém o código efetivo para a operação. 9.4.8 Polimorfismo O polimorfismo permite tratar instâncias de várias classes da mesma forma dento do sistema. Ex: O objeto Francisco pode ser um estudante, um registro ou mesmo um coordenador. É interessante haver uma importância para os outros objetos saberem que tipo de pessoa Francisco é. O esforço no desenvolvimento seria reduzido se outros tipos de objetos tratassem o objeto pessoa da mesma forma, não existindo códigos separados para cada tipo. 9.4.9 Interface A interface é um contrato de implementação de métodos de uma classe, onde a classe que implementa uma interface, deve implementar todos os métodos que são especificados pela interface. 9.5 Conclusão A análise orientada a objeto tem como principal objetivo fazer com que o mundo computacional torne-se o mais próximo possível do mundo real. Com o auxílio de todos os conceitos que citamos, é possível representar computacionalmente os objetos do mundo real e classificá-los em classes reconhecíveis. Módulo 10 UML Na disciplina de Estrutura de Sistemas de Informação, fizemos uma rápida passagem sobre a UML onde falamos da sua importância na modelagem dos sistemas de informação. Neste capítulo, nos aprofundaremos mais na UML, dando maior ênfase os seus diagramas, que são poderosas ferramentas utilizadas na modelagem de sistemas. A UML surgiu para resolver o grande problema existente no desenvolvimento de Softwares utilizando a orientação a objeto, que é a modelagem. Não existia uma notação padronizada que proporcionasse abrangência a qualquer tipo de aplicação que se desejasse, além de resultar em várias simbologias e terminologias diferentes, originando assim uma grande confusão para os desenvolvedores. Com o lançamento da UML, grande parte dos desenvolvedores de softwares ficaram entusiasmados com a notícia, pois esse tipo de padronização já era esperado há muito tempo.

É interessante observar que a UML tem como característica, abordar o caráter estático e dinâmico do sistema que está sendo avaliado, proporcionando já na modelagem, características futuras do sistema com relação a linguagem utilizada, banco de dados e algumas outras especificações finais do sistema. 10.1 Objetivos da UML Proporcionar a modelagem de sistemas utilizando todos os conceitos da orientação a objeto; Fixar uma junção nos métodos conceituais, tornando-os executáveis; Definir uma linguagem de modelagem que possa ser utilizada tanto pelo homem, quanto pela máquina. A UML tem como característica ser uma linguagem de modelagem dominante, sendo baseada em padrões e conceitos que foram testados em metodologias anteriores. 10.2 A Utilização da UML A UML pode ser utilizada no desenvolvimento dos mais variados tipos de sistemas, pois tem como característica abranger qualquer atributo do sistema, utilizando os seus diagramas nas diferentes fases de desenvolvimento. O objetivo principal é descrever qualquer tipo de sistema utilizando diagramas orientados a objeto. Citaremos abaixo alguns sistemas e suas características: Sistemas de informação: Tem como característica principal o armazenamento, pesquisa, edição e demonstração de informações para os seus usuários. É um sistema que possui uma grande quantidade de relacionamentos, que envolve certa complexidade, além de armazenar uma grande quantidade de informações em bases de dados relacionais ou orientadas a objetos. Sistemas em tempo real: Os sistemas em tempo real são executados por Hardwares específicos integrados a veículos, aparelhos telefônicos, eletrodomésticos etc. Utilizam uma programação de baixo nível requerendo suporte em tempo real. Sistemas distribuídos: Têm como característica principal serem distribuídos por várias máquinas, onde a transferência de dados entre ambas é feito facilmente, possuindo mecanismos de sincronização que garantem a integridade dos dados. 10.3 Notações da linguagem UML

A UML é composta por algumas notações que são utilizadas para modelar os mecanismos gerais de um sistema. Todas estas notações em conjunto, permitem especificar e exemplificar a definição de um sistema no que diz respeito às suas funcionalidades, estáticas e dinâmicas. Falaremos um pouco sobre cada um desses componentes, focalizando mais a fundo nos diagramas. 10.3.1 Visões O principal atributo das visões é a demonstração dos diferentes aspectos existentes no sistema que está sendo modelado. A visão não é considerada um gráfico, mas sim uma abstração que é constituída por uma série de diagramas. Com a definição do número de visões, cada uma será responsável por demonstrar aspectos do sistema, onde é dado um maior enfoque aos ângulos e níveis de abstrações diferentes, e com isso será possível gerar uma figura completa do sistema. 10.3.2 Modelos de elementos Os conceitos que são utilizados nos diagramas, são modelos de elementos que têm como característica, representar as definições mais comuns da orientação a objeto como as classes, os objetos, as mensagens, os relacionamentos, etc. Ilustraremos abaixo o conjunto dos principais elementos de estrutura: Agora ilustraremos os principais elementos de comportamento (estados e mensagens), agrupamento (pacotes) e anotações.

10.3.3 Tipos de relações Em um conceito geral, as relações apresentam uma sintaxe e uma semântica bem definida, permitindo o estabelecimento de interdependência entre os elementos básicos citados acima. Módulo 11 UML 11.3.4 Diagramas A UML é composta por diagramas que juntos podem modelar vários tipos de sistemas. Como falamos anteriormente, a maioria dos sistemas possuem estruturas estáticas e estruturas dinâmicas. As estruturas estáticas podem ser modeladas pelos diagramas de classe e de objeto. As estruturas dinâmicas são modeladas pelos diagramas de estado, seqüencia, colaboração e atividade. Os diagramas de componentes e execução são suportados pelo modelo funcional. Apresentaremos algumas características dos diagramas existentes na UML: 11.3.4.1 Diagrama de caso de uso: é utilizado na demonstração de relacionamentos entre atores e casos de uso. Os atores representam o papel de uma entidade externa ao sistema, como um usuário, um hardware, ou um outro sistema. Os atores iniciam a comunicação com o sistema através dos casos de uso, onde esses casos de uso representam uma seqüência de ações que são executadas pelo sistema.

11.3.4.2 Diagrama de classe: é utilizado na demonstração da estrutura estática das classes de um sistema, onde estas classes representam as coisas que são gerenciadas pelo sistema que está sendo modelado. Um classe pode se relacionar com outra através das: Associações: classes conectadas entre si. Dependências: uma classe depende de outra classe. Especialização: uma classe é uma especialização de outra classe. Pacotes: classes que são agrupadas por possuírem características similares. No diagrama de classe são apresentados todos esses relacionamentos e suas estruturas internas que são os atributos e as operações.

11.3.4.3 Diagrama de seqüência: Mostra o dinamismo existente entre a colaboração dos vários objetos de um sistema. A partir do diagrama de seqüência é possível perceber a seqüência de mensagens que são enviadas entre os objetos, mostrando a interação entre os objetos e o que acontecerá em um ponto específico na execução do sistema. 11.3.4.4 Diagrama de colaboração: Ilustra de maneira semelhante ao diagrama de seqüência o dinamismo existente na colaboração dos objetos. Em alguns casos pode se escolhe em utilizar o diagrama de colaboração ou o diagrama de seqüência. 11.3.4.5 Diagrama de estado: O diagrama de estado funciona como um complemento para a descrição das classes, mostrando todos os estados possíveis que o objeto de uma dada classe pode se encontrar, e apresentar quais são os eventos do sistema que provocam tais mudanças.

11.3.4.6 Diagrama de atividade: Foca o trabalho executado na implementação de um método, e suas atividades em uma instância de um objeto. É uma variação do diagrama de estado, possuindo um propósito um pouco diferente que é o trabalho e as atividades que serão executadas e os seus resultados no que diz respeito a mudança de estado dos objetos. 11.3.4.7 Diagrama de componente: Mostra o sistema por um lado funcional onde são expostas as relações existentes entre os seus componentes e a execução dos seus módulos durante a execução.

11.3.4.8 Diagrama de execução: Ilustra a arquitetura de hardware e software do sistema, juntamente com as conexões que são estabelecidas entre si. Especifica os componentes executáveis e os objetos que são alocados para ilustrar quais unidades são executadas. O uso de um tipo ou outro de diagrama depende na maioria das vezes do grau de detalhamento que é requerido para o desenvolvimento do sistema. Os diagramas mais utilizados são os de classe, caso de uso e o diagrama de seqüência. Para uma boa utilização da UML, é recomendado o uso de ferramentas CASE para o auxílio na construção de diagramas. Módulo 12 FERRAMENTAS CASE O significado da palavra CASE tem sofrido ao longo dos tempos várias interpretações, a mais utilizada é COMPUTER AIDED SOFTWARE ENGINEERING ou Engenharia de Software Auxiliada por Computador. Se analisarmos em um primeiro momento, observamos que o termo CASE não se refere diretamente a algum tipo de ferramenta, mas se observamos a expressão auxiliada por computador, chegamos a conclusão de que este auxílio só pode ser alcançado com a utilização de algum tipo de ferramenta.

Segundo B. Terry CASE designa um conjunto de ferramentas que auxilia um programador ou desenvolvedor de projetos durante uma ou mais fases no processo de desenvolvimento de software, onde é incluído também a sua manutenção. Podemos definir o significado CASE como um conjunto de ferramentas e técnicas que auxiliam os desenvolvedores de software na construção de aplicativos, visando a diminuir o esforço e a complexidade, melhorar o controle do projeto, aplicar processos automatizados para que seja gerado um produto final de qualidade. Um dos principais objetivos a serem alcançados com a utilização das ferramentas CASE, é a implementação de um ambiente integrado que permita abordar desde a fase de concepção até a implementação, sendo muito importante para o desenvolvimento de sistemas de informação. Em alguns momentos, foram observados comprometimentos com a utilização de ferramentas CASE, pois em um dado momento pode existir a incapacidade de suportar de forma integrada, todas as atividades nas várias fases do processo, sobretudo, na geração automática de código. Algumas preocupações são reforçadas, principalmente por causa de alterações significativas que acontecem nos vários níveis tecnológicos envolvidos, métodos de análise e desenhos, modelagens de alto nível e a implementação do código. Alguns estudos não apresentam consistência nas vantagens de se utilizar estas ferramentas, pois se alguns apontam vantagens em sua utilização, outros chegam a conclusão que seus benefícios são difíceis de serem atingidos. 12.1 Evolução das ferramentas CASE Desde o início foi constatada a necessidade de se utilizar ferramentas para o auxílio no desenvolvimento de softwares. Citaremos abaixo, algumas fases em que as ferramentas de auxílio foram surgindo. Primeira fase: Tradutores Compiladores Pré-processadores Segunda fase Editores de texto Debuggers Verificadores de código Software para controle de versão No início da década de 70 surgiu o sistema operacional Unix e seus respectivos aplicativos, que foram apontados como um dos primeiros conjuntos de ferramentas integradas de apoio ao desenvolvimento de software. No final

da década de 80 surgiram as primeiras ferramentas de geração automática de código. Nos anos 90, muitas ferramentas CASE foram designadas como ferramentas RAD (Rapid Application Development), que aumentavam o ritmo de desenvolvimento dos aplicativos. Exemplos de ferramentas RAD: Visual Basic Delphi PowerBuilder Oracle Designer Oracle Developer A introdução da orientação a objeto revolucionou o mercado, fazendo com que algumas ferramentas tradicionais incorporassem novas técnicas de modelagem, integrando com as abordagens estruturadas existentes. A UML assume papel de destaque neste contexto, crescendo a cada dia a nível denotação para modelagem. Hoje em dia, toda ferramenta incorpora suporte a UML. 12.2 Classificação das ferramentas CASE Ferramentas UPPER-CASE: Aplicações que se especializam na fase de concepção do software, incluindo análise, especificação e modelagem de requisitos. Ferramentas LOWER-CASE: Aplicações que são utilizadas na fase de implementação em que estão envolvidos os desenhos técnicos, compilação de código e os testes. Citaremos agora algumas ferramentas CASE em uma classificação mais detalhada: 1. Modelagem de processo de negócios: a. ARIS TOOLSET ( WWW.ids-scheer.com ) b. MEGA SUITE ( WWW.mega.com ) c. PROVISION ( WWW.proformacomp.com ) 2. Modelagem de análise e desenho do sistema:

a. ROSE ( www.rational.com ) b. PARADIGM PLUS ( WWW.cai.com ) c. GDPRO (WWW.advancedsw.com ) d. SYSTEM ARCHITECT ( WWW.popkin.com ) e. POWERDESIGNER ( WWW.sysbase.com ) 3. Programação de Aplicativos: a. VISUAL BASIC ( WWW.microsoft.com) b. DELPHI ( WWW.borland.com ) c. POWERBUILDER ( WWW.sysbase.com ) 4. Modelagem de banco de dados: 5. Teste a. SYSTEM ARCHITECT ( WWW.popkin.com ) b. ERWIN (WWW.cai.com ) c. POWERBUILDER ( WWW.sysbase.com ) a. SUITE TESTSTUDIO ( WWW.rational.com ) b. TESTWORKS ( WWW.soft.com ) 6. Gestão de Projetos: a. PROJECT ( WWW.microsoft.com ) b. JUGGLER ( WWW.cse.dcu.ie/catalyst ) 12.3 Funcionalidades das ferramentas CASE 12.3.1 Funcionalidades que são comuns a todas as ferramentas: Definição de grupos e perfis de utilizadores; Manter um registro de todas as alterações efetuadas; Suporte ao trabalho em equipe; Reutilizar artefatos de outros projetos já utilizados. 12.3.2 Funcionalidades específicas: Possibilidade de representar fases, tarefas e atividades que são executadas ao código do projeto; Possibilidade de comparar os esforços planejados com os já realizados; Possibilidade de atribuir atividades e recursos, e analisar a alocação de cada recurso; Possibilidade de utilizar um histórico para elaborar um novo projeto; Possibilidade de analisar prazos e questões financeiras.

Citamos algumas funcionalidades que são comum a todas as ferramentas, e algumas específicas, mas sabemos que as funcionalidades das ferramentas CASE não se resumem apenas a estas citadas. Observamos que algumas tendências nos últimos anos com as ferramentas CASE são idênticas as outras áreas dos sistemas de informação. A crescente utilização de linguagens orientadas a objeto e a utilização de ambientes de desenvolvimento, facilitam o crescimento do mercado de ferramentas de modelagem, onde a UML assume um papel de destaque neste crescimento. Módulo 13 ANÁLISE, DEFINIÇÃO E ESPECIFICAÇÃO DE REQUISITOS A análise de requisitos busca compreender os requisitos solicitados pelo cliente para a construção dos sistemas de informação. É nela que são descritas as abordagens utilizadas para descobrir os requisitos, envolvendo uma equipe técnica que em conjunto com os usuários do sistema, estabelecem um domínio da aplicação do sistema. Neste processo de análise, usuários como gerentes, engenheiros de manutenção e especialista de domínio também estão envolvidos, sendo conhecidos como STAKEHOLDERS. Alguns problemas são encontrados na análise de requisitos, citaremos alguns: O usuário do sistema não possui uma idéia concreta do que deseja, e mesmo sabendo, existe uma grande dificuldade em se expressar. O usuário tenta se expressar utilizando seus próprios termos, supondo que o desenvolvedor sabe o que ele está falando. Como os requisitos são definidos por diferentes usuários, são ocasionados diversos conflitos, sendo eles difíceis de serem descobertos, pois os usuários se expressam de formas diferentes. 13.1 Processo de Análise dos Requisitos Para que sejam descobertos os requisitos de um sistema, deve ser estabelecida uma compreensão sistemática. O modelo é composto pelas seguintes atividades: Compreensão do domínio: É estabelecido um entendimento do domínio da aplicação, onde deve-se procurar descobrir o maior número de informações possíveis. Coleção de requisitos: É feito um processo de interação com os usuários envolvidos, com a intenção de identificar os requisitos. Classificação: Classificar a lista de requisitos em categorias coerentes.

Resolução de Conflitos: Identificação e resolução de requisitos, decidindo o que fazer quando os requisitos solicitados por um usuário entram em conflito com outros já existentes. Priorização: Definições de quais requisitos possuem uma maior prioridade. Validação: Verificar se o conjunto de requisitos é compatível com os solicitados pelos usuários. Durante a atividade de análise, três atividades podem ser desenvolvidas: Particionamento: Identifica o relacionamento estrutural entre as atividades. Abstração: Identifica a generalidade entre as atividades. Projeção: Identifica as diferentes formas possíveis de se enxergar o mesmo problema. 13.2 Tipos de requisitos 13.2.1 Requisitos Funcionais Os requisitos funcionais representam algo que o sistema deve fazer como uma função do sistema que agregue valor ao usuário que está utilizando. Um exemplo de requisito funcional é a emissão de relatório ou a realização de um cadastro. Os eventos essenciais têm como função principal a definição de todos os requisitos funcionais existentes no sistema, respondendo a todos os eventos. O levantamento correto de requisitos funcionais não é uma tarefa fácil, mas a metodologia essencial fornece traços gerais que são eficientes para esta tarefa, sendo perfeitamente adequados para os sistemas de informação. 13.2.2 Requisitos não funcionais Os requisitos não funcionais abordam a forma como os requisitos funcionais podem ser alcançados, definindo restrições e propriedades de um sistema. Alguns requisitos não funcionais também são conhecidos como requisitos de qualidade, que são responsáveis por exigir resistência e robustez do sistema. Em alguns casos descobrir quais são os requisitos não funcionais do sistema é tão difícil quanto produzir uma especificação do sistema que possa cumprir a um custo razoável e um tempo hábil, as especificações que foram exigidas pelos usuários. Como exemplo dessas dificuldades apresentadas, existem dois requisitos não funcionais que se relacionam de forma inversa, sendo eles a velocidade e a sua transportabilidade. Para se produzir um software muito rápido, é necessário que ele se adapte ao ambiente que ele está funcionando, e para