Introdução aos Sistemas de Informação

Transcrição

1 0 Introdução aos Sistemas de Informação Sumário: Definição de Sistema de Informação. Problemas no desenvolvimento de Sistemas de Informação. Soluções: Tecnologia; Métodos de desenvolvimento. Linguagens de modelação.

2 1 O que é um Sistema de Informação? Sistema. s. m. Reunião de partes ligadas entre si, formando uma estrutura complexa. Conjunto de meios, processos destinados a produzir um resultado = Método. Informação. s. f. Conjunto de conhecimentos reunidos sobre um determinado assunto; documentação. Dicionário de Língua Portuguesa Contemporânea. Academia de Ciências de Lisboa. Sistema de Informação: Fornece um meio para reunir informação de uma dada organização, fornecendo procedimentos para registo e disponibilização dessa informação, com o objectivo de auxiliar a organização nas suas actividades. Não é necessariamente um sistema software; Existem vários tipos de sistemas de informação...

3 2 Uma taxonomia para Sistemas de Informação Diferentes tipos de Sistemas de Informação (SI): Sistemas de Informação para Executivos Sistemas de Informação para a Gestão Sistemas de Suporte à Decisão Sistemas de Trabalho Baseados em Conhecimento Sistemas de Automação de Escritórios Sistemas de Processamento de Transacções Etc. Atenção: Taxonomias são sempre redutoras! Esta taxonomia representa uma visão funcional dos SI. Visão funcional meio tecnológico para registar, guardar e disseminar informação. Visão estrutural colecção de pessoas, processos, dados, modelos tecnologia e linguagens.

4 Uma taxonomia para Sistemas de Informação

5 4 Uma taxonomia para Sistemas de Informação (II) Sistemas de Processamento de Transacções Recolhem e armazenam informação acerca de transacções (eventos de interesse); Controlam alguns aspectos relativos às transacções. Sistemas de Automação de Escritórios Fornecem meios para o processamento de dados ao nível do indivíduo; Incluem o processamento de texto, folhas de cálculo, etc. Sistemas de Trabalhos Baseados em Conhecimento Auxiliam na criação e integração de novos conhecimentos na organização.

6 5 Uma taxonomia para Sistemas de Informação (II) Sistemas de Suporte à Decisão Auxiliam a tomada de decisões fornecendo informação, modelos ou ferramentas de análise. Sistemas de Informação para a Gestão Analisam a informação produzida pelos Sistemas de Informação Transaccionais; Convertem informação sobre transacções em informação de controlo de desempenho e gestão da organização. Sistemas de Informação para Executivos Evolução dos Sistemas de Informação para a Gestão vocacionada para executivos; Permitem análise da informação de forma simples e interactiva e a diferentes níveis de detalhe.

7 6 Uma taxonomia para Sistemas de Informação (IV) Sejam de que tipo forem, os SI: existem para auxiliar a organização " mais um meio a juntar a (tantos) outros; devem ser concebidos em função das necessidades da organização " vão ser utilizados pela organização, não por quem os concebeu. É necessário perceber a organização para conceber um bom SI. Quais as actividades da organização a suportar. Qual a informação relevante que flui na organização. Quais as tarefas das pessoas da organização. Entender o problema antes de desenvolver a solução!

8 7 O que é um bom Sistema (de Informação) Aquele que satisfaz as necessidades dos seus utilizadores: útil e utilizável bom software facilita a vida dos utilizadores - deve responder às necessidades reais dos utilizadores (usabilidade! ); confiável sem bugs! flexível as necessidades dos utilizadores mudam, os bugs têm que ser corrigidos bug do ano 2k veio mostrar a falta de flexibilidade de muitos sistemas; acessível (financeiramente) quer na compra quer na manutenção - fácil e rápido de desenvolver; disponível se não está disponível nada mais interessa! - está disponível a tempo e horas? está disponível na plataforma tecnológica pretendida? Como vai o desenvolvimento de software?

9 8 Estatísticas sobre desenvolvimento de Software Sobre o produto entregue... Fonte: Eason, 1988

10 9 Estatísticas sobre desenvolvimento de Software (II) Sobre o produto pago... 3% 2% Mais de 75% do software pago não chegou a ser utilizado! Apenas 5% do software pago foi utilizado continuadamente (deste, 3% necessitou de correcções). 19% 47% 29% Pago mas não entregue Entregue mas não utilizado Utilizado mas mais tarde alterado ou abandonado Entregue e utilizável depois de correcções Entregue e utilizado Fonte: GAO, 1992

11 10 Estatísticas sobre desenvolvimento de Software (III) Sobre o processo... Inquérito realizado em 1994 a 352 companhias (Standish Group): 56% de todos os bugs pode ser atribuídos a erros cometidos durante a fase de análise (i.e., não se esteve a construir o sistema certo!) 31% de todos os processos de desenvolvimento de software são cancelados antes de estarem terminados. 53% dos projectos custam 189% do estimado. 9% dos projectos de grandes companhias respeitam os prazos e o orçamento. 16% dos projectos de pequenas companhias respeitam os prazos e o orçamento. Mais alguns dados sobre grandes projectos (>50,000 linhas de código): produtividade média está abaixo das 10 linhas de código por dia; em média, encontram-se 60 erros por cada 10,000 linhas de código; custo de manter o software ultrapassa o dobro do custo de desenvolvimento.

12 11 Estatísticas sobre desenvolvimento de Software (IV) Tipos de erro: Erro devido a causas físicas o sistema físico de suporte falha; Erro de software os (nossos) conhecidos bugs; Erro humano o operador do sistema utiliza-o de forma errada. Resultados de alguns estudos: 60%-90% de todas as falhas são atribuíveis a erro humano (Hollnagel, 1993). 92% das fatalidades consideradas num estudo entre 1979 e 1992 podiam ser atribuídas a problemas na interacção humano-computador, apenas 4% a causas físicas e 3% a erros de software (MacKenzie, 1994). Mas... Erro de qual humano?! Do humano que utiliza o sistema, ou do humano que o desenhou/implementou?

13 12 Estatísticas sobre desenvolvimento de Software (V) Exemplos Alguns exemplos de sistemas com problemas atribuíveis ao software: Sonda Mariner I, Julho de 1962 Deveria ter voado até Vénus. Apenas quatro minutos após o lançamento despenhou-se no mar. Descobriuse depois que um operador de negação lógica tinha sido omitido por acidente no código do programa responsável por controlar os foguetes... Therac-25, finais dos anos 80 Máquina de Raios-X totalmente controlado por software. Diversos problemas provocaram a administração de radiação excessiva a vários doentes. Aeroporto Internacional de Denver, início dos anos 90 Sistema de tratamento de bagagem envolvendo mais de 300 computadores. O projecto excedeu os prazos de tal forma que obrigou ao adiamento da abertura do aeroporto (16 meses). Foi necessário mais 50% do orçamento inicial para o pôr a funcionar. Ariane 5, Junho de 1996 Explodiu no voo inaugural devido a uma série de falhas no software de navegação. Em circunstâncias específicas era efectuada uma divisão por zero. O sistema de segurança consistia em ter redundância: em caso de erro os dados eram processados por outro programa (uma cópia do primeiro! abordagem adequada para hardware, mas não para software).

14 13 Estatísticas sobre desenvolvimento de Software (VI) Em conclusão: Problemas com o desenvolvimento de software: Atrasos na entrega. Incumprimento dos orçamentos. Falha na identificação e satisfação das necessidades dos clientes. Produtos entregues com falhas. Algumas causas para o problema: Complexidade dos sistemas tem vindo a aumentar Quanto mais o hardware evolui, mais somos tentados a atacar problemas cada vez mais complexos. Condições de utilização do software são cada vez menos controladas Cada vez se torna mais difícil prever como/onde o software será utilizado.

15 14 Desenvolvimento de Software (Riscos) Desenvolver um bom sistema não é tarefa trivial Riscos associados aos requisitos. Riscos tecnológicos. Riscos de competência. Riscos políticos.

16 15 Desenvolvimento de Software (Riscos) Desenvolver um bom sistema não é tarefa trivial (versão moderna!)

17 16 Desenvolvimento de Software (Riscos) (II) Riscos associados aos requisitos É necessário comunicar com os peritos da organização para: compreender que tarefas o sistema deve suportar; compreender como o sistema encaixa nas actividades da organização. Um dos maiores desafios é construir o sistema certo. Riscos Tecnológicos Qual a tecnologia mais apropriada? Como controlar a complexidade? É necessário validar as soluções tecnológicas o mais cedo possível. Riscos de Competência É necessário saber-se o que se está a fazer (obviamente?). Exemplo de OO: fácil de aprender/difícil de dominar. Riscos Políticos Por muito bom que seja o SI só terá sucesso se tiver o apoio das pessoas certas.

18 17 Respostas I - Tecnologia Primeiras abordagens à Crise do Software preocupavam-se mais com a produtividade do que com a qualidade. As tecnologias de programação têm vindo a tornar-se cada vez mais sofisticadas (tanto aos níveis dos paradigmas como das ferramentas). Paradigmas de Programação O modo como estruturamos o código tem vindo a evoluir como resposta ao aumento da complexidade do software: Programação estruturada (70's) Estruturar o código para controlar complexidade. Programação modular Estruturar o código, mas também os dados. Programação orientada aos objectos (80's) Aumenta o poder expressivo na estruturação de dados/código. Programação orientada aos aspectos (90's) Estruturação passa a ser feita, não em termos de objectos, mas em termos de aspectos de interesse.

19 18 Respostas I Tecnologia (II) Orientação aos Objectos Mundo visto como sendo composto por objectos com identidade própria e capacidade de interacção uns com os outros Vantagens reclamadas pela orientação aos objectos: uma formal natural e compreensível de pensar/programar; uma forma robusta e estável de programar; facilita a manutenção dos sistemas e aumenta a produtividade Quatro aspectos fundamentais da orientação aos objectos: Identidade (dos objectos); Classificação (objecto como instância da sua classe); Polimorfismo (operação+classe=método); Herança. (super/sub-classes)

20 19 Respostas I Tecnologia (III) Identidade cada objecto tem identidade própria; podem existir objectos iguais; continuam, no entanto, a serem distintos (cf. gémeos). Classificação os objectos agrupam-se em classes; todos os objectos de uma mesma classe possuem o mesmo conjunto de propriedades (atributos), o mesmo comportamento (operações) e as mesmas relações com outros objectos. Polimorfismo a mesma operação pode ter comportamentos diferentes em objectos de classes diferentes; é uma forma de abstracção. Herança (Especialização/Generalização) classes são organizadas de acordo com as suas similitude e diferenças; facilita a reutilização.

21 20 Respostas I Tecnologia (IV) Abstracção prestar atenção aos aspectos essenciais, ignorando os detalhes irrelevantes; nível de abstracção? demasiada abstracção, crie-se uma sub-classe (especializa-se); demasiado detalhe, crie-se uma super-classe (generaliza-se); O desenvolvimento passa a middle-out. Encapsulamento dados e operações correspondentes são agrupados numa única entidade. Information hiding (ocultação de informação) torna-se possível esconder o estado (dados) dos objectos; acesso aos dados passa a ter que ser efectuado (de forma mais controlada) através das operações. Representation hiding (ocultação da representação) ao ocultarmos os dados, passa também a ficar oculta a forma como estes estão representados.

22 21 Respostas I Tecnologia (V) Ferramentas Ambientes de Desenvolvimento Integrado (IDEs) cada vez mais sofisticados procuram facilitar a tarefa de programação (e também de análise). Ferramentas para o UML IBM Rational inicialmente da Rational, agora da IBM; Together inicialmente da TogetherSoft, agora da Borland; Poseidon (versão community edition); Visual Paradigm (versão community edition); ArgoUML argouml.tigris.org (open source /BSD) plugins para NetBeans, Eclipse, Jbuilder, etc. etc., etc., etc.

23 22 Respostas II Métodos de Desenvolvimento Mas... A tecnologia só por si não resolve os problemas (e estes têm vindo a aumentar!) A tecnologia é apenas uma ferramenta, é necessário saber como utilizá-la Hoje em dia a Crise do Software tem muito a ver com a qualidade do produto final. São necessários métodos de desenvolvimento que garantam produtividade e qualidade. método do Lat. methodu < Gr. méthodos, caminho para chegar a um fim s. m., processo racional que se segue para chegar a um fim; modo ordenado de proceder; processo; ordem; conjunto de procedimentos técnicos e científicos; (

24 23 Respostas II Métodos de Desenvolvimento (II) Processo de desenvolvimento Um processo define quem está a fazer o quê, quando e como tendo em vista atingir um dado objectivo (Jacobson et al. 99) Um processo: Identifica um conjunto de regras que definem como o desenvolvimento de um sistema deve ser efectuado. Inclui, normalmente, uma descrição dos documentos que devem ser produzidos e em que ordem. Pode incluir indicação da linguagem (de modelação) a ser utilizada para a produção dos documentos. Método de desenvolvimento: Processo de desenvolvimento + Linguagem de modelação

25 24 Respostas II Métodos de Desenvolvimento (III) Waterfall Análise Desenho Implementação Testes Manutenção Este tipo de processo define uma série de etapas executadas sequencialmente. Assume que é sempre possível tomar as decisões mais correctas irrealista!

26 25 Respostas II Métodos de Desenvolvimento (IV) Estrela Implementação Análise de tarefas/ Análise funcional Prototipagem Avaliação Prototipagem Especificação de Requisitos Neste tipo de processo coloca-se em destaque a necessidade de avaliar o sistema em todas as fases de desenvolvimento.

27 26 Respostas II Métodos de Desenvolvimento (V) Espiral Especificar Implementar Testar Avaliar Analisar requisitos Analisar riscos Planear Neste tipo de processo reconhece-se a necessidade de iterar para controlar riscos.

28 27 Respostas II Métodos de Desenvolvimento (VI) (Rational) Unified (software development) Process Um processo: guiado por casos de uso (use cases); centrado na arquitectura do sistema a desenvolver; iterativo e incremental: Início; Elaboração; Construção; Transição.

29 28 Unified Software Development Process Sumário: Breve história do Unified Process O Unified Process O ciclo de vida do Unified Process O RUP (Rational Unifed Process)

30 29 Breve História do Unified Process Rational Unifed Process Booch, Rumbaugh & Jacobson Rational Objectory Process Booch, Rumbaugh & Jacobson Rational Approach Objectory Process Booch & Rumbaugh Jacobson Ericsson Jacobson Finais dos anos 60

31 30 O Unified Process O Unified Process é: Uma framework para o processo de desenvolvimento, genérica e adaptável. O Unifed Process fomenta: O desenvolvimento baseado em componentes. O Unified Process utiliza: A UML como ferramenta de modelação durante todas as fases do processo de desenvolvimento. Três ideias chave Desenvolvimento guiado por Use Cases (Casos de Uso). Desenvolvimento centrado na arquitectura. Desenvolvimento iterativo e incremental.

32 31 Desenvolvimento guidado por Use Cases Um use case representa uma interacção entre o sistema e um humano ou outro sistema; O modelo de use cases é utilizado para: guiar a concepção do sistema (captura de requisitos funcionais); guiar a implementação do sistema (implementação de um sistema que satisfaça os requisitos); guiar o processo de testes (testar que os requisitos são satisfeitos).

33 32 Desenvolvimento centrado na arquitectura O modelo de use cases descreve a função do sistema, o modelo da arquitectura descreve a forma; O modelo arquitectural permite tomar decisões sobre: O estilo de arquitectura a adoptar; Quais os componentes do sistema e quais as suas interfaces; A composição de elementos estruturais e comportamentais.

34 33 Desenvolvimento iterativo e incremental Permite dividir o desenvolvimento em pedaços geríveis"; Em cada iteração: identificar e especificar use cases relevantes; criar uma arquitectura que os suporte; implementar a arquitectura utilizando componentes; verificar que os use cases são satisfeitos. Selecção de uma iteração: grupo de use cases que extendam a funcionalidade; aspectos de maior risco.

35 34 Ciclo de vida do Unified Process

36 35 Fases do Unified Process (I) Início Identificar o problema. Definir âmbito e natureza do projecto. Fazer estudo de viabilidade. Resultado da fase: decisão de avançar com o projecto. Elaboração (Análise / Concepção Lógica) Identificar o que vai ser construído (quais os requisitos?). Identificar como vai ser construído (qual a arquitectura?). Definir tecnologia a utilizar. Resultado da fase: uma arquitectura geral (conceptual) do sistema.

37 36 Fases do Unifed Process (II) Construção (Concepção Física/Implementação) Processo iterativo e incremental. Em cada iteração tratar um (conjunto de) Use Case: análise / especificação / codificação / teste / integração Resultado da fase: um sistema de informação! Transição Realização dos acertos finais na instalação do sistema. Optimização, formação. Resultado da fase: um sistema instalado e 100% funcional (espera-se!).

38 37 O RUP (Rational Unifed Process) O RUP é uma concretização do Unified Process. O RUP fornece: ferramentas de gestão do processo de desenvolvimento segundo a framework definida pelo Unified Process (ver página 51); ferramentas para a modelação e desenvolvimento baseadas no UML; uma base de conhecimento (knowledge base). Na verdade as coisas passaram-se um pouco ao contrário...

39 38 Apresentação da UML Sumário: UML Vantagens da utilização de modelos Problemas com a utilização de modelos Breve história do UML Diagramas do UML

40 39 UML Unified Modelling Language (Booch, Jacobson & Rumbaugh) a UML foi pensado para o desenvolvimento de sistemas orientados aos objectos, mas é independente das linguagens de programação a utilizar permite explorar o paradigma OO (cf. riscos tecnológicos) a UML possibilita o trabalho a diferentes níveis de abstracção facilita comunicação e análise (cf. riscos de requisitos) a UML não é uma linguagem, mas uma família de linguagens gráficas para modelar e construir sistemas software inclui modelos para as diferentes fases do desenvolvimento a UML não é um processo de desenvolvimento de software, mas pode ser utilizado com diferentes processos a UML é um standard mantido pelo OMG (Object Management Group) a UML é suportado por ferramentas Rational Rose (IBM), Together (Borland), Visual Paradigm, Poseidon, etc., etc.

41 40 Linguagens de Modelação Permitem-nos escrever modelos da solução a desenvolver. Modelos: Thinking made public ; Simplificações da realidade representações abstractas de um sistema, efectuadas de um ponto de vista específico. Abstracção: Mecanismo poderoso para lidar com a complexidade; Uma linguagem de modelação tem: léxico regras que definem quais os elementos válidos da linguagem; sintaxe regras que definem quais as combinações válidas dos elementos; semântica regras que definem o significado dos modelos legais. A linguagem UML é diagramática modelos são expressos com diagramas.

42 41 Linguagens de Modelação (II) Tipos de Modelos: Preditivos Utilizados para prever o comportamento de um sistema. Normativos Utilizados para definir comportamentos adequados do sistema. Descritivos Utilizados para descrever a estrutura e comportamento do sistema. Na UML: Utilizam-se vários modelos para representar uma mesma realidade (os modelos não são a realidade) Utilizam-se vários diagramas para representar um modelo (os diagramas não são os modelos) De uma forma geral, os modelos UML são descritivos.

43 42 Vantagens da utilização de modelos Auxiliam a compreender a realidade. Sendo abstracções da realidade, os modelos permitem descrever o que é considerado essencial num dado contexto, escondendo detalhes desnecessários/ irrelevantes nesse contexto. Ajudam a comunicar ideias de forma simplificada. Sendo simplificações da realidade, permitem comunicar apenas os aspectos pretendidos. Ajudam a documentar as decisões tomadas durante o desenvolvimento. Os modelos desenvolvidos constituem uma base documental para a descrição do processo de desenvolvimento Thinking made public.

44 43 Problemas com a utilização de modelos Mais uma linguagem a aprender. Isso acarreta custos, quer monetários (para as organizações), quer cognitivos (para os indivíduos). Modelos apresentam uma visão idealizada da realidade. Existe o risco de durante o processo de modelação nos esquecermos que os modelos são representações da realidade e não a realidade. É necessário considerar se estamos a utilizar abstracções adequadas e a modelar todos os aspectos relevantes. A fase de modelação atrasa a produção de código (pseudo-problema!) Espera-se, no entanto, que o código produzido seja de melhor qualidade (assim como o próprio sistema desenvolvido). Uma abordagem iterativa e incremental soluciona este problema. Por outro lado, é já possível passar, de forma semi-automática, dos modelos para o código. Regra dos 5/6 1/6 (análise e concepção vs. Codificação) Atenção à analysis paralysis!

45 44 Breve história da UML Anos 60 Simula 67 é a primeira linguagem orientada aos objectos; Anos 70 Aparece o Smalltalk; Anos 80 as linguagens orientadas aos objectos (OO) tornam-se utilizáveis: Smalltalk estabiliza; surgem o Objective C, C++, Eiffel, CLOS, etc. Finais dos anos 80 surgem as primeiras metodologias de modelação OO Anos 90 existem dezenas de metodologias de modelação OO: Shlaer/Mellor, Coad/Yourdon, Booch, OMT (Rumbaugh), OOSE (Jacobson), etc. meados dos anos 90 começam as tentativas de unificação dos métodos 1994 Rumbaugh junta-se a Booch na Rational Software Corporation 1995 Booch e Rumbaugh apresentam a versão 0.8 do Unified Method (viria depois a mudar de nome para Unified Modelling Language); Jacobson junta-se a Booch e Rumbaugh 1996 o OMG (Object Management Group) pede propostas para um standard de modelação OO Setembro, 1997 a Rational, em conjunto com outras empresas (HP, IBM, Oracle, SAP, Unisys,...), submete a UML 1.0 ao OMG como proposta de standard (existiram outras propostas) Novembro, 1997 a UML é aprovado como standard OO pelo OMG; o OMG assume a responsabilidade do desenvolvimento da UML Anos a UML é aceite como norma ISO (ISO/IEC 19501) 2006 a UML 2.0 está em desenvolvimento

46 UML - EVOLUÇÃO

47 46 Diagramas da UML A UML define os seguintes oito diagramas base: Diagramas de Use Case. Diagramas de Classe Diagramas Comportamentais Diagramas de Interacção Diagramas de Sequência Diagramas de Comunicação (ou Colaboração) Diagramas de máquinas de estado (ou Statecharts) Diagramas de Actividade Diagramas de implementação Diagramas de componentes Diagramas de Instalação (Deployment) Diagramas UML

48 47 A escolha dos modelos a utilizar tem uma grande impacto na forma como um dado problema é abordado e, consequentemente, na solução que se irá atingir. A Abstracção (prestar atenção aos detalhes importantes e ignorar os irrelevantes) é um factor fundamental. Assim: Todo o sistema complexo deve ser abordado através de um pequeno conjunto de vistas/modelos tão independentes quanto possível; Cada modelo pode ser expresso a diferentes níveis de detalhe; Os melhores modelos são aqueles que têm relação directa com a realidade. Os oito tipos de diagramas identificados anteriormente procuram cobrir todas as necessidades de modelação que ocorram durante o desenvolvimento de software.

49 48 Os diagramas não são os modelos! / Os modelos não são o sistema!

50 MOTIVAÇÃO - IMPORTÂNCIA Stephen Seidman, The Path to Software Engineering Professionalism, Join 08, Sept., U. Minho

51 MOTIVAÇÃO - IMPORTÂNCIA Stephen Seidman, The Path to Software Engineering Professionalism, Join 08, Sept., U. Minho

52 MOTIVAÇÃO - IMPORTÂNCIA O desenvolvimento de software ainda tem muito de arte e muito pouco de verdadeira Engenharia. Quando um software de computador é bem-sucedido quando satisfaz as necessidades das pessoas que o usam, tem desempenho sem falhas por um longo período, é fácil de modificar e ainda mais fácil de usar, ele pode e efetivamente modifica as coisas para melhor. Mas, quando o software falha quando os seus utilizadores ficam insatisfeitos, quando tem tendência a erros, quando é difícil de modificar e ainda mais difícil de usar acontecem coisas desagradáveis. Todos nós desejamos construir software que torne as coisas melhores evitando os problemas que espreitam na sombra dos esforços mal sucedidos. Para obter sucesso, precisamos de disciplina e método quando o software é projectado e construído. Precisamos de uma abordagem de engenharia. R. Pressman, Engenharia de Software, McGraw Hill, 6ª. Ed., 2005.

53 MOTIVAÇÃO - IMPORTÂNCIA Abordagem de Engenharia ao Questões importantes 1. Definir um Processo 2. Usar Modelos abstractos do Sistema a conceber e implementar 3. Possuir Métodos rigorosos 4. Usar Ferramentas de apoio ao projecto

54 MOTIVAÇÃO - IMPORTÂNCIA Um Processo de Desenvolvimento de Software consiste de uma estruturação das várias disciplinas ou fases que estão contidas na filosofia de desenvolvimento de software adoptada por uma dada organização para o desenvolvimento do produto sistema software. Mas, fundamentalmente, consiste em definir QUEM no projecto está a fazer O QUÊ, QUANDO o deve fazer e DURANTE quanto tempo, e como se devem atingir os objectivos definidos. Requisitos dos clientes Processo de Desenvolvimento de SW Sistema Software

55 MOTIVAÇÃO - IMPORTÂNCIA A nossa abordagem de Engenharia ao Desenvolvimento de Sistemas Software, passa por algumas ideias fundamentais, a saber: Adoptar o Rational Unified Process (RUP) como processo de base para o desenvolvimento; Seguindo o RUP, apostar na Modelação Orientada aos Objectos; Seguindo o RUP, usar UML (standard da OMG), como notação de modelação; Definir alguma metodologia na utilização dos modelos UML. Realizar o desenvolvimento integrado e coerente de todas as camadas do sistema software, desde a camada de dados até à camada interactiva.

56 ABORDAGEM EM DSS Tal como noutras áreas, talvez a táctica esteja correcta, mas são a visão (a estratégia) e a dinâmica (o processo) as questões que são fundamentais. Seguiremos uma estratégia Orientada aos Objectos e uma dinâmica parcialmente alinhada pelo RUP ( Rational Unified Process ) mas também pelos processos AGILE, não rígidos.

57 UML: Unified Modeling Language Objectivos: Modelação, Comunicação, Teste e Documentação das várias facetas/aspectos de um sistema software intensive Linguagem de modelação visual (+ algum texto) É um standard de facto v v v Não é metodologia/processo: não diz quem deve fazer o quê, quando e como; É rigorosa mas não formal; Pode ser usada por diferentes metodologias; É, hoje, a base da designada Model Driven Software Engineering (MDSE).

58 UML: DIAGRAMAS e MODELOS VISÕES FUNDAMENTAIS: ESTRUTURAL e COMPORTAMENTAL

59 E DEPOIS METODOLOGIA Domain Model + Use Case Model são depois refinados sistematicamente nos outros modelos, estruturais e comportamentais, idealmente diferenciando objectos que são de camadas distintas (dados, computacional, negócio e IU).

60 59 Diagramas de Use Case Sumário: Definição de requisitos Diagramas de Use Case I conceitos base Diagramas de Use Case II conceitos avançados Resumo Exercícios

61 60 Definição de requisitos Definição de requisitos do sistema, duas abordagens possíveis: Visão estrutural interna Visão orientada aos use case externa Visão Estrutural (OO) Definir classes; Definir métodos das classes; Definir interface com o utilizador (comportamento do sistemas face ao utilizador); Problemas: O que interessa ao utilizador é o comportamento do sistema, no entanto a interface com o utilizador só é definida no final do processo. Perigo de o sistema não fornecer toda a funcionalidade pretendida; Perigo de o sistema fornecer funcionalidade não pretendida (= despedício de trabalho).

62 61 Definição de requisitos (II) Visão orientada aos Use Case Identificar actores quem vai interagir com o sistema? Identificar Use Case o que se pretende do sistema? Identificar classes de suporte à realização dos use case como vai a funcionalidade necessária ser implementada? Vantagens: Não há trabalho desnecessário; O Sistema de Informação suporta as tarefas do cliente.

63 62 Definição de Use Case Uma unidade coerente de funcionalidade um serviço define um comportamento do sistema sem revelar a estrutura interna apenas mostra a comunicação entre sistema e actores o conjunto de todos os use case define a funcionalidade do sistema deve incluir o comportamento normal, bem como variações (erros, etc.) vamos definir o comportamento com texto estruturado; vamos também definir as pré-condições e pós-condições de cada use case (cf. design by contract).

64 63 Design by contract Design by contract (DBC) baseia-se na noção de um contrato entre um cliente e um fornecedor para a realização de um serviço. O conceito central do DBC é a asserção (uma asserção é uma expressão booleana que nunca deverá ser falsa). Tipicamente as asserções são automaticamente testadas durante a fase de debug. O DBC identifica três tipos de asserções: pré-condições condições que se devem verificar para a invocação de um dado serviço ser válida; pós-condições condições que se devem verificar após a execução de um serviço; invariantes asserções que se devem verificar durante o tempo de vida da entidade a que se aplicam. A partir da versão 1.4 o Java passou a ter asserts que podem ser utilizados para definir pré- e pós-condições no entanto não suporta invariantes).

65 64 O use case para fazer um telefonema: Use Case: Fazer Telefonema Pré-condição: Telefone ligado e em descanso Comportamento normal: 1. Utilizador marca número e pressiona OK 2. Telefone transmite sinal de chamada 3. Utilizador aguarda 4. Telefone estabelece ligação 5. Utilizador fala 6. Utilizador pressiona tecla C 7. Telefone desliga chamada Comportamento Alternativo: 3. Telefone Transmite sinal de ocupado 4. Utilizador pressiona tecla C 5. Telefone cancela chamada Comportamento Alternativo: 3. Telefone cancela chamada Pós-condição: Telefone ligado e em descanso

66 65 Identificação de Use Cases Podemos identificar os Use Case do sistema a partir da identificação de cenários de utilização. Um cenário descreve um contexto concreto de interacção entre o utilizador e o sistema. Por Exemplo: Durante o semestre o Prof. Faísca foi enviando os sumários com breves resumos da matéria leccionada, via , para o sistema Fly2. Após o fim das aulas, o Prof. Faísca utilizou a interface web do sistema para actualizar cada um dos sumários com descrições mais completas das matérias leccionadas. Finda essa actualização, imprimiu os sumários e enviou-os à Secretaria. A partir dos cenários podemos identificar os Use Cases (serviços) necessários à correcta disponibilização da funcionalidade requerida pelo mesmo.

67 66 Identificação de Use Cases (II) No cenário anterior podemos identificar os seguintes Use Case: 1. Enviar sumários via web 2. Actualizar sumários via web 3. Imprimir sumários (via web? / via ?) 4. Enviar sumários à secretaria deverá este use case ser considerado? No cenário descrito o envio é feito em papel. Não se trata, portanto, de um serviço fornecido pelo sistema. No entanto, podemos discutir a possibilidade de o envio passar a ser feito electronicamente estariamos a alterar o modo de trabalho inicialmente previsto/actual! Durante o semestre o Prof. Faísca (1.) foi enviando os sumários com breves resumos da matéria leccionada, via , para o sistema Fly2. Após o fim das aulas, o Prof. Faísca (2.) utilizou a interface web do sistema para actualizar cada um dos sumários com descrições mais completas das matérias leccionadas. Finda essa actualização, (3.) imprimiu os sumários e (4.) enviou-os à Secretaria.

68 67 Diagramas de Use Cases conceitos base Modelam o contexto geral do sistema. Quais os actores que com ele se relacionam e que use case deve suportar. A concepção do sistema é guiada pelo modelo de use case: Utilizam-se use cases para capturar os requisitos funcionais do sistema de uma forma sistemática; O modelo de use case captura toda a funcionalidade requerida pelos utilizadores; A implementação do sistema é guiada pelo modelo de use case: cada use case é implementado sucessivamente: quando todos os use cases estiverem implementados obtém-se o sistema final; fica facilitada a manutenção do sistema sempre que os requisitos sejam alterados; O modelo de use case é utilizado para o planeamento de testes: Após a definição do modelo de use case: planear black-box testing. Após a implementação dos use cases: planear white-box testing.

69 68 Black-box testing Utilizado para verificar se o sistema implementa toda a funcionalidade pretendida. Permite detectar erros de omissão (funcionalidade não implementada). White-box testing Utilizado para verificar se o sistema implementa a funcionalidade de forma correcta. Permite detectar erros na implementação da funcionalidade pretendida.

70 69 Exemplo de diagrama de Use Cases Sistema Actor Associação Use Case

71 70 Sistema define as fronteiras do sistema Use Case (novamente) Uma unidade coerente de funcionalidade um serviço define um comportamento do sistema sem revelar a estrutura interna apenas mostra a comunicação entre sistema e actores o conjunto de todos os use case define a funcionalidade do sistema deve incluir o comportamento normal, bem como variações (erros, etc.) vamos definir o comportamento com texto estruturado; vamos também definir as pré-condições e pós-condiçõoes de cada use case (cf. design by contract).

72 71 Actor uma abstracção para uma entidade fora do sistema um actor modela um propósito (alguém que tem um interesse específico no sistema) pode não mapear 1 para 1 com entidades no mundo real um actor não é necessariamente um humano pode ser um computador, outro sistema, etc. cada actor define um conjunto de papeis que utilizadores do sistema podem assumir o conjunto de todos os actores definem todas as formas de interacção com o sistema Associação representa comunicação entre o actor e o sistema através de use cases

73 72 Novamente a gestão de sumários Sistema de gestão de sumários e presenças. Etapas a cumprir (com o auxílio de cenários de utilização do sistema): 1. Identificar actores 2. Identificar use cases 3. Identificar associações Identificar actores Quem vai utilizar o sistema? Neste caso: Docente, Secretaria e Aluno Identificar use cases Objectivos dos utilizadores/actores? Resposta a estimulos externos.

74 73 Novamente a gestão de sumários (II) Identificar associações Que actores utilizam que use cases? Nem sempre é imediatamente evidente se a comunicação entre o sistema em análise e sistemas externos deve ser representada. Quatro abordagens podem ser identificadas: mostrar todas as associações; mostrar apenas as associações relativas a interacção iniciada por sistemas externos; mostrar apenas as associações relativas a interacções em que é o sistema externo o interessado no use case; não mostrar associações com sistemas externos.

75 74 Todas as associações Todos os sistemas externos que interagem com o sistema em análise são apresentados como actores e todas as interacções são representadas nos diagramas. Demasiado abrangente, em muitos casos existem interacções com outros sistemas apenas por razões de implementação e não por se tratarem de requisitos do sistema. Apenas as associações relativas a interacção iniciada por sistemas externos Só são representados como actores os sistemas externos que iniciem diálogo com o sistema em análise. Mesmo assim muito abragente.

76 75 Apenas as associações em que é o sistema externo o interessado Neste caso só são apresentados como actores os sistemas externos que necessitam de funcionalidade fornecida pelo sistema em análise. Usalmente esta é uma solução equilibrada. Não mostrar associações com sistemas externos Apenas os utilizadores são actores, neste caso quando existem sistemas externos apresentam-se os seus actores em diálogo directo com o sistema a ser modelado. De uma outra forma esta solução também é demasiado abrangente e pode levar a confusão sobre quem está realmente a utilizar o sistema.

77 76 Novamente a gestão de sumários (III) Visão geral versão 1 Faz sentido estar aqui? Falta mecanismo de autenticação!

78 77 Novamente a gestão de sumários (IV) Visão geral versão 2 são adicionadas pré-condições nos use case Gerir Sumários, Gerir Presenças, Gerir Disciplinas e Registar Presença a exigir que tenha sido feito login.

79 78 Diagramas de Use Cases conceitos avançados «include» Um estereótipo de dependência. Utilizado para indicar a reutilização de comportamento. Actores utilizam os use case base. Quando o use case base é executado, também o use case incluido o é

80 79 Use Case: Remover Aula Comportamento normal: 1. «include» Ler código 2. Sistema apresenta Aula 3. Actor confirma remoção 4. Sistema confirma realização da remoção Comportamento Alternativo: 3. Actor cancela remoção Comportamento Alternativo: 2. Sistema indica que não existe aula com esse código. Use Case: Alterar Aula Comportamento normal: 1. «include» Ler código 2. Sistema apresenta Aula 3. Actor altera dados e confirma alteração 4. Sistema confirma realização da alteração Comportamento Alternativo: 3. Actor cancela alteração Comportamento Alternativo: 2. Sistema indica que não existe aula com esse código.

81 80 Também pode ser utilizado para estruturar use cases. Não exagerar! Em alternativa, utilizar sub-diagramas.

82 81 «extend» Outro estereótipo de dependência. Permite adicionar comportamento a um use case base. Estratégia: escrever caso base; identificar variações; utilizar extensões para elas. Caso base deve ser um use case bem formado sem as extensões! Extensão pode não ser um use case bem formado por si só.

83 82 Generalização/Especialização Sub-elementos são casos particulares de super-elementos. Um sub-elemento pode ser utilizado onde quer que o super-elemento possa. Útil para user profiling (definição de níveis de acesso). Nos exemplos apresentados: Existem duas formas de fazer login. O actor Admin pode realizar todos os use cases de Docente e Secretaria.

84 83 Diagramas de Use Case Resumo Os diagramas de Use Case permitem definir os requisitos funcionais de um sistema: que serviços deve fornecer; a quem os deve fornecer. Notação diagramática facilita o diálogo (com os clientes e dentro da quipa de desenvolvimento). Utilizando diagramas de use case, clientes e equipa de desenvolvimento podem chegar a um acordo sobre qual o sistema a desenvolver. A resolução de alterações nos requisitos funcionais fica facilitada. No entanto: Os diagramas de use case não suportam a captura de requisitos não funcionais. Quando utilizar diagramas de Use Case? Sempre que se estiverem a analisar requisitos!

85 84 Diagramas de Use Case Estratégia Use Case Driven FMM2007

86 CONHECIMENTO FUNDAMENTAL O QUE É UM SISTEMA DE INFORMAÇÃO? Um Sistema de Informação é hoje entendido como um sistema computacional, ou seja, um conjunto de componentes de hardware e de software, em geral software intensive, ou seja, fundamentalmente com a inteligência residente no software e a capacidade de processamento residente no hardware e na sua respectiva arquitectura, mas que tem por objectivo crucial fornecer um conjunto de procedimentos para o registo, o tratamento, a análise e a apropriada disponibilização de informação relevante para os diferentes níveis de responsabilidade de gestão e decisão, típicas de uma organização moderna. Os diferentes níveis de responsabilidade e de necessidade de informação/conhecimento dentro das organizações, e, em consequência, os diferentes tipos de SI necessários às organizações, estão hoje muito bem caracterizados.

87 CONHECIMENTO CLÁSSICO Em resumo, qualquer que seja o seu tipo ou missão, os SI são criados sempre com os seguintes objectivos em mente: Apenas existem para auxiliar (em eficácia e eficiência) a organização cliente; Quem deve definir requisitos e objectivos é a organização cliente, mas os projectistas podem dar ideias durante a fase de concepção; Antes de criar o SI os projectistas devem tentar compreender o melhor possível a organização, o seu negócio e a sua estrutura de gestão; Devem também compreender de forma rápida quais as pessoas dentro da organização que vão ser os reais utilizadores do SI (cf. os 3 níveis que se apresentaram antes); Devem compreender qual a informação relevante que flui na organização e que parte dela vai passar a integrar o SI DESENVOLVIMENTO DE SISTEMAS SOFTWARE F. Mário Martins (cf. domain model );

88 CONHECIMENTO CLÁSSICO Compreendida a missão (desenvolver Sistemas Software úteis e eficazes usando procedimentos de Engenharia), compreendido o enquadramento (para as organizações, sejam de comércio, serviços, ou indústria), e conhecendo até alguma história de insucesso, o que precisamos de saber e aprender para que se possa inverter tal história e, de 1.- facto, Adoptar deixar um Processo a arte e enveredar de desenvolvimento pela engenharia de Sistemas e, assim, por Software um maior que nos rigor garanta? tais metas, em especial depois de conhecermos a história dos processos desenvolvidos; O processo adoptado deverá dar, justificadamente, muitas mais garantias de sucesso no desenvol-vimento dos actuais e futuros SI (ou Sistemas Software); 2.- Adoptar/Criar Métodos, ou seja, regras sobre como fazer, desde como fazer a captura de requisitos até como fazer a instalação, os testes e a manutenção; 3.- Adoptar Ferramentas que representam o suporte automático DESENVOLVIMENTO DE SISTEMAS SOFTWARE F. Mário Martins ou semi-automático aos processos e aos métodos.

89 CONHECIMENTO CLÁSSICO MODELOS DO PROCESSO DE SOFTWARE São todos relativamente consensuais quanto às várias fases do processo, apenas diferem quanto à dinâmica de execução de tais fases. Vamos definir tais fases com base num modelo mais antigos, o modelo de desenvolvimento sequencial puro, por isso designado em cascata ou waterfall. Assume pura sequência de fases, sem retorno, e que tudo corre bem logo à 1ª : é irrealista!! DESENVOLVIMENTO DE SISTEMAS SOFTWARE F. Mário Martins

90 CONHECIMENTO CLÁSSICO Modelo em Espiral As várias fases de projecto são realizadas de forma iterativa, ou seja, procura-se garantir que só se transita para uma fase mais estável depois de fixadas as fases anteriores. Não é um modelo fácil, porque impõe uma estrututura e uma dinâmica de modificação de projecto, em geral, não suportada pela metodologia e pelas ferramentas actuais. DESENVOLVIMENTO DE SISTEMAS SOFTWARE F. Mário Martins

91 CONHECIMENTO CLÁSSICO O RUP (Rational Unified Process) será para nós a abordagem seguir. DESENVOLVIMENTO DE SISTEMAS SOFTWARE F. Mário Martins

92 CONHECIMENTO CLÁSSICO AS DISCIPLINAS SÂO CONSENSUAIS: CAPTURA DE REQUISITOS: Depois de os estudos de viabilidade, etc., em geral não realizados, indicarem que o Sistema é viável e útil para a organização, haverá que realizar a captura (percepção e entendimento) de todos os requisitos do mesmo, quer do ponto de vista funcional (o que deve ser capaz de fazer, funções e serviços), quer de outros ANÁLISE pontos E MODELAÇÃO de vista não CONCEPTUAL: funcionais No (qualidades dia a dia, e restrições usamos muitas de desenvolvimento, vezes sistemas abstractos tais como que compatibildade nos ajudam a de compreender, tecnologias, de prazos forma de sintéctica, entrega, etc.). partes específicas dos complexos sistemas físicos. Por exemplo, um Mapa do Metro de uma dada cidade (abstracção), auxilia-nos a relacionar as diferentes linhas do metro com as ruas da cidade (sistemas físicos) que o mapa representa. Mas o mapa DESENVOLVIMENTO é, naturalmente DE SISTEMAS SOFTWARE apenas um sistema F. Mário Martins abstracto, 2008 um32 modelo, uma síntese da realidade.

93 CONHECIMENTO CLÁSSICO AS DISCIPLINAS SÂO CONSENSUAIS: CONCEPÇÃO/DESIGN/ESPECIFICAÇÃO: Fase na qual, após todas as análises realizadas na fase anterior, se determina, escreve, de forma mais ou menos rigorosa, o que o Sistema Software deve ser capaz de fazer, informação que é fundamental para os programadores, assim sejam eles capazes de compreender as especificações que lhes são passadas. Na prática, nada disto acontece ETC: Mas há algumas perspectivas mais concretas, em especial baseadas numa abordagem por objectos, a todo o processo de desenvolvimento de software, tal como proposto pelo OMG ( Object Management Group ), de credibilidade universal. DESENVOLVIMENTO DE SISTEMAS SOFTWARE F. Mário Martins

94 OBJECT MANAGEMENT GROUP DESENVOLVIMENTO DE SISTEMAS SOFTWARE F. Mário Martins

95 are Engineering: A Practitioner's Approach, 6/e O QUE DIZ O RUP O RUP (Rational Unified Process) será para nós a abordagem seguir. DESENVOLVIMENTO DE SISTEMAS SOFTWARE F. Mário Martins

96 O QUE DIZ O RUP Processo de Desenvolvimento de Software que é iterativo e incremental As várias fases são divididas em séries de mini-fases que corres-pondem a sucessivas versões mais completas dos sistemas. DESENVOLVIMENTO DE SISTEMAS SOFTWARE F. Mário Martins

97 O QUE DIZ O RUP RUP é use-case driven Os Use Cases (Casos de Uso) são instrumentos funda-mentais do processo, porque na fase de captura de requisitos são os use cases que irão representar os requisitos de funcio-nalidade do sistema e definir as interacções com o sistema, necessárias para deste se obter tal funcionalidade. DESENVOLVIMENTO DE SISTEMAS SOFTWARE F. Mário Martins

98 O QUE DIZ O RUP RUP é use-case driven "Use case driven" means writing the user manual first, then writing the code. This practice reinforces the fundamental notion that a system must conform to the needs of the users, instead of your users conforming to the system. [Doug 2001] Especificação da sequência de interacções que são necessárias para se obter o serviço DESENVOLVIMENTO DE SISTEMAS SOFTWARE F. Mário Martins

99 O QUE DIZ O RUP RUP baseia-se na criação de múltiplos modelos usando UML Um modelo é uma representação simplificada de um aspecto da realidade existente ou a construir, com um propósito específico; Específico da engenharia: modelar qq. coisa ainda não existente para melhor a criar. Estrutura + Comportamento Nota: 1 aspecto => 1..* modelos Mm: Espaço de modelação Mr: Mundo real DESENVOLVIMENTO DE SISTEMAS SOFTWARE F. Mário Martins

100 Modelos são conjuntos de diagramas + texto; Diagramas são vistas de um modelo; DESENVOLVIMENTO DE SISTEMAS SOFTWARE F. Mário Martins

101 USE CASES UML Diagram Structure Diagram Behaviour Diagram Classes Components Objects Composite Deployment Packages Use Cases Activity Machine States Component Interaction Sequence Collaboration Interaction Timing DESENVOLVIMENTO DE SISTEMAS SOFTWARE F. Mário Martins

102 USE CASES: Elementos Diagramas de Use Case especificam O QUE um sistema deve funcionalmente fazer, tal como observável de um ponto de vista externo (humano ou não, p.e., outro sistema). Conceitos: Actores, Use Cases e Sujeito (sistema). DESENVOLVIMENTO DE SISTEMAS SOFTWARE F. Mário Martins

103 USE CASES Use Case = Uma funcionalidade do sistema (software ou não). DESENVOLVIMENTO DE SISTEMAS SOFTWARE F. Mário Martins

104 USE CASES DESENVOLVIMENTO DE SISTEMAS SOFTWARE F. Mário Martins

105 Em resumo, Use Case = Uma funcionalidade do sistema (software ou não).

106 USE CASES Um actor representa um papel ( role ) que alguém ou qualquer coisa externa ao sistema representa, ao ser responsável por iniciar os eventos necessários (interagir) para que uma determinada tarefa se cumpra. Uma pessoa pode corresponder a vários actores e viceversa. Um use case é um resumo de todos os possíveis cenários para a realização de uma dada tarefa ou obtenção de um dado objectivo (goal). É comum um use case ter vários actores envolvidos. O que falta? Modularidade, estruturação e reutilização! Que relações são típicas da abordagem OO?

107 USE CASES Não esquecer que cada use case diagramático irá ser depois especificado textualmente passo a passo (exº em Visual Paradigm).

108 USE CASES: <<include>> Semântica Operacional: Invocação de uma subrotina <<include>> diz-se um estereótipo (uma marca especial)

109 USE CASES: <<include>>

110 USE CASES: Importância São uma forma intuitiva e sistemática de capturar requisitos funcionais; São a base de todo o processo de desenvolvimento; Permitem identificar melhor as tarefas que são os objectivos dos utilizadores do sistema; Identificam o que o sistema deve fazer para cada tipo de utilizador; Especificam todas as possíveis utilizações do sistema; São instrumento de diálogo entre clientes e projectistas; Permitem desenvolver protótipos da Interface com o Utilizador.

111 USE CASES: Exemplo IBM - RUP

112 USE CASES: a continuar Artigo para ler sobre Use Cases: Use Cases: Yesterday, Today, and Tomorrow Ivar Jacobson (o pai!)