O Essencial Da Análise de Sistemas

O Essencial da Anlise de Sistemas
lvaro Rocha
Universidade Fernando Pessoa

2008
ndice
1- Introduo 2- Desenvolvimento de Sistemas de Informao 3- Anlise de Sistemas 4- Determinao de Requisitos 5- Anlise Estruturada 6- Anlise Orientada a Objectos
1 3 10 32 53 82
lvaro Rocha (2008), O Essencial da Anlise de Sistemas. UFP
Pgina ii
Captulo 1
1.
Introduo
Como estudiosos da rea dos Sistemas de Informao (SI), temos verificado a consciencializao crescente em relao importncia das Tecnologias de Informao (TI), como crucial para o sucesso das organizaes. De facto, os Sistemas de Informao e as Tecnologias de Informao associadas tm uma contribuio importantssima na definio e no alcance dos objectivos da estratgia das organizaes, tal como na obteno de factores de diferenciao e de mais-valias perante a concorrncia. As potencialidades oferecidas actualmente pelas Tecnologias da Informao implicam que no seja mais possvel encarar os Sistemas de Informao apenas na perspectiva
Pgina 1
ultrapassada de meros sistemas de suporte aos processos de negcio, mas antes como indutores de processos de negcio inovadores. Assim, a Anlise de Sistemas, vista como a actividade onde se pensam e definem os Sistemas de Informao, assume crucial importncia no processo de Desenvolvimento de Sistemas de Informao (DSI). Com a falta de literatura, pelo menos em portugus, que possa fornecer aos estudantes, professores e profissionais da rea dos Sistemas e Tecnologias de Informao quadros de referncia para a problemtica da Anlise de Sistemas, em particular de uma base de conceitos relacionada com os seus fundamentos, abordagens, principais mtodos e tcnicas, e o modo como se organizam as suas principais actividades, decidimos prestar o nosso contributo atravs da escrita deste livro. Para alm deste captulo, o livro organiza-se em mais quatro. No Captulo 2, enquadramos a actividade anlise de sistemas no processo de desenvolvimento de sistemas de informao. No Captulo 3, apresentamos e discutimos fundamentos da anlise de sistemas bem como a organizao das suas actividades. No Captulo 4, apresentamos um conjunto de tcnicas para determinao de requisitos de sistemas de informao. No Captulo 5, apresentamos o essencial da metodologia Anlise Estruturada, nomeadamente os modelos propostos e as tcnicas subjacente elaborao destes mesmos modelos. No Captulo 6, apresentamos o essencial da metodologia Anlise Orientada a Objectos, nomeadamente os modelos propostos e as tcnicas subjacente sua elaborao. Finalmente, apresentamos o vasto conjunto de bibliografia que suportou o
desenvolvimento dos contedos apresentados neste livro.
Pgina 2
Captulo 2
2.
Desenvolvimento de Sistemas de Informao
2. 1 Introduo Neste livro, Desenvolvimento de Sistemas de Informao (DSI) entendido como um processo de mudana que visa melhorar um subsistema de informao de uma organizao e, consequentemente, colaborar na melhoria do seu sistema de informao global. 2. 2 Domnios de mudana no DSI Num processo de DSI devem ser considerados trs domnios de mudana: tecnologia, linguagem e organizao. A tecnologia cobre os meios fsicos e o saber fazer ("know-how") tcnico pelo qual as tarefas de processamento de dados so consumadas. Por linguagem entendida qualquer forma de representao simblica que transporta significado. Isto inclui conversao, mas tambm sistemas de processamento de dados convencional. Finalmente, organizao, cobre elementos tais como procedimentos e arranjos de trabalho, papeis, posies, poder, valores, normas e cultura bem como competncias tcnicas e aptides para realizar processos de trabalho.
lvaro Rocha (2008), O Essencial da Anlise de Sistemas. UFP Pgina 3
Lyytinen (1987) diz que estes domnios so exaustivos e argumenta que se ordenam hierarquicamente do modo seguinte:
"Tecnologia, ou em geral, o mudo fsico, a base para o domnio da linguagem, porque a linguagem sempre representada em algum material portador. Por outro lado a linguagem necessria para qualquer aco social organizada dentro do foco do domnio organizacional".
O domnio tcnico de significado axiomtico porque os Sistemas de Informao (SI) so vistos como baseados em computador. O domnio da linguagem enfatiza que um SI define uma linguagem formalizada a ser usada para comunicar sobre algo do domnio do discurso. A importncia crescente do redesenho, redefinio ou reengenharia dos processos de negcio tem aumentado o interesse no domnio organizacional, implicando que os SI tenham de ser altamente sensitivos organizao e que o desenvolvimento de SI e o desenvolvimento organizacional tenham de ser muito entrelaados. 2.3 Interpretaes para o Desenvolvimento de SI Um processo de DSI pode ser realizado por vrios motivos. Carvalho (1996) agrupa-os em trs interpretaes: Construo de Sistema Informtico: quando se tem uma viso restrita do SI, i.e., tendo somente em conta os aspectos tcnico/tecnolgicos. Assim um SI visto como um sistema informtico (ou aplicao informtica), que no mais do que um sistema (baseado em computador) que suporta a recolha, o armazenamento, o processamento e a distribuio de dados numa funo da organizao, podendo, por vezes, no se integrar no SI global. Desenvolvimento de Sistema de Informao: quando se tem em conta todos os aspectos relacionados com a melhoria do SI da organizao. O objectivo compreender a organizao e a forma como est a ser suportada pelo SI. Em suma, pretende-se melhorar o sistema de informao que a suporta. Uma avaliao das TI disponveis poder levar construo de sistemas informticos para suporte do SI.
Redefinio Organizacional: quando o DSI realizado no mbito de intervenes ao nvel dos processos e da organizao, sendo, deste modo, visto como uma (sub)actividade da redefinio de processos organizacionais. Uma vez modificado o modo como o negcio conduzido ser tambm necessrio rever a forma como o sistema de informao suporta o negcio e que sistemas informticos podero ser construdos/utilizados. A deciso de intervir ao nvel organizacional deriva de uma avaliao do potencial estratgico das TI disponveis. O objectivo analisar a forma como as TI podem ser utilizadas para potenciar mudanas significativas no modo como o negcio conduzido e, eventualmente, levar a organizao obteno de vantagens competitivas. A construo de sistemas informticos corresponde a uma postura tcnica prxima da engenharia de software, podendo ento considerar-se como uma viso restrita do DSI. Por outro lado, a redefinio organizacional traduz preocupaes de gesto do negcio. A nfase aqui posta nos processos organizacionais, sendo o DSI colocado em segundo plano. No desenvolvimento de sistemas de informao, a construo de sistemas informticos um sub-problema que poder mesmo no se pr, quer por ser considerado desnecessrio o suporte informtico, quer pelo facto de as aplicaes informticas julgadas necessrias e adequadas poderem ser obtidas a partir de terceiros. No entanto, mesmo que a construo de sistemas informticos no ocorra na organizao, a definio/alocao1 dos seus requisitos uma actividade importante do DSI. O DSI assim visto como uma actividade prxima da engenharia de sistemas/informao. Das interpretaes de DSI apresentadas depreende-se que a construo de sistemas informticos pode resultar de uma interveno somente ao nvel do sistema informtico, de uma interveno ao nvel do sistema de informao ou, ainda, de uma interveno ao nvel do sistema organizacional (SO). Por vezes confunde-se desenvolvimento de sistemas de informao com construo de sistemas informticos. De facto, apesar da construo de aplicaes informticas ocupar um espao grande no DSI, espera-se que esta viso possa mudar, passando de finalidade a uma parte ou sequncia normal do desenvolvimento.
Alocar requisitos significa encontrar um subconjunto de requisitos do sistema que so para ser implementados nas componentes de software do sistema. lvaro Rocha (2008), O Essencial da Anlise de Sistemas. UFP Pgina 5
1
Portanto, o DSI no deve ser visto como automatizao de sistemas e processos existentes, mas sim como meio de os melhorar e racionalizar, ou ainda como forma de proporcionar processos completamente novos. 2.4 Actividades Tradicionais de DSI Na prtica, como ilustra a figura 2.1, o DSI engloba a anlise, concepo, construo e implementao de sistemas de informao, e uma parte importante dessa prtica a anlise, concepo, construo e implementao de sistemas informticos, i.e., subsistemas de informao suportados em computador.
Engenharia de Sistemas
Engenharia de Software
Anlise
Concepo
Construo
Implementao
Figura 2.1: Actividades tradicionais no desenvolvimento de SI.
No primeiro caso, as duas primeiras actividades geralmente so vistas como engenharia de sistemas, e no segundo caso como engenharia de software. Actualmente considera-se que a engenharia de software deve ocorrer em consequncia da actividade engenharia de sistemas. Em vez de se concentrar somente no software, a engenharia de sistemas foca-se numa variedade de elementos, consistindo na anlise, concepo e organizao desses elementos num sistema que pode ser um produto, um servio, ou uma tecnologia para transformao ou controlo de informao. Por vrias razes, o desenvolvimento/construo de sistemas informticos (i.e., engenharia de software) tem recebido mais ateno do que o desenvolvimento de sistemas informao em sentido lato (i.e., engenharia de sistemas).
Pgina 6
2.5 Descrio das Actividades de DSI A anlise essencialmente uma actividade de percepo. Exige-se ao analista, a capacidade de identificar conjuntamente com os utilizadores os processos e respectivos requisitos de uma rea/actividade da organizao, recorrendo para isso a mecanismos adequados. Do resultado devem constar modelos/especificaes de sistemas novos, independentes da tecnologia que os suportar. Nesta fase exige-se ao analista capacidade de abstraco de modo a reconhecer, analisar e resolver problemas do (sub)SI. Actualmente, esta actividade tambm conhecida por engenharia de requisitos2 (figura 2.2). No caso da engenharia de sistemas, e porque o software sempre parte de um sistema maior, a anlise comea por estabelecer os requisitos para todos os elementos do sistema e depois aloca algum subconjunto desses requisitos ao software. Esta viso essencial quando o software tem de estar ligado com outros elementos tais como hardware, pessoas e bases de dados. No caso da engenharia de software, o processo de obteno de requisitos intensificado e focado especialmente no software. Para entender a natureza do software a construir, o engenheiro de software (analista informtico) tem de entender os requisitos de informao do domnio do discurso, bem como funes, comportamentos, desempenhos e ligaes requeridas. Com a concepo pretende-se criar a especificao tcnica detalhada para construo (ou programao) do sistema, nomeadamente, estrutura de dados, estrutura do software, interfaces e algoritmos de procedimentos detalhados, traduzindo os requisitos em representaes de software.
A adopo do novo nome deve-se preocupao de se querer incorporar uma orientao de engenharia nesta actividade, adicionando-lhe mais rigor e disciplina. O uso do termo engenharia implica que tcnicas sistemticas e repetitivas devem ser usadas para assegurar que os requisitos dos sistemas so relevantes, consistentes e completos. lvaro Rocha (2008), O Essencial da Anlise de Sistemas. UFP Pgina 7
A construo consiste na implementao tcnica, ou seja, na codificao e teste do sistema especificado na concepo, recorrendo a uma linguagem de programao; ou na gerao automtica de cdigo atravs de ferramentas CASE3, quando estas so capazes de suportar de forma integrada a concepo e construo de sistemas. Por ltimo, a implementao consiste em pr a funcionar correctamente na organizao o sub-SI, tendo em conta aspectos como a sua integrao no SI global, formao dos utilizadores e controlo de qualidade com a finalidade de manter e avaliar o sucesso do sistema. 2.6 Possveis Alteraes s Actividades Tradicionais de DSI Apesar da sequncia tradicional de actividades apresentada continuar a ser a mais encontrada nas organizaes, verifica-se que o desenvolvimento de sistemas de informao um processo em mudana, principalmente por motivos tcnicos, humanos e financeiros. Assim, actualmente frequente ver as actividades de concepo e construo serem substitudas pela subcontratao ou pela aquisio de pacotes de software, como ilustra a figura 2.2.
Engenharia de Requisitos
Concepo Anlise
Construo Implementao
Subcontratao ou Pacote
Figura 2.2: Alteraes s actividades tradicionais de desenvolvimento de SI.
CASE sigla de Computer Aided Software Engineering. As ferramentas CASE consistem num conjunto de ferramentas de desenvolvimento baseadas em computador, capazes de automatizar partes do processo de desenvolvimento, aumentando assim a qualidade e a produtividade. Geralmente estas ferramentas suportam metodologias de desenvolvimento clssicas.
Pgina 8
A subcontratao consiste no acto de subcontratao de parte (ou de toda) uma actividade interna a um fornecedor externo, normalmente com vantagens para a organizao. Neste caso consiste no desenvolvimento medida de um sistema informtico por terceiros. J um pacote de software uma aplicao informtica existente no mercado, pronta a usar pela organizao. Por vezes necessrio adaptar a aplicao s caractersticas especficas da organizao ou, nos piores casos, alterar algumas especificidades da organizao em favor dela. Um dos pontos fracos da generalidade dos gestores o hbito de procurarem pacotes sem a devida anlise dos requisitos reais dos utilizadores. A poltica de aquisio de pacotes ou desenvolvimento por terceiros leva a que, no processo de DSI, a (sub)actividade anlise/engenharia de requisitos assuma um papel ainda mais especial e importante do que j assume num processo de desenvolvimento tradicional, porque servir como referencial para a seleco do pacote que mais se adequar aos requisitos estabelecidos ou at como caderno de encargos quando o desenvolvimento subcontratado a terceiros. Neste ltimo caso, a falta de um bom documento de anlise poder implicar em problemas graves para o cliente, uma vez que no ter forma de provar/reivindicar que o sistema solicitado no efectivamente o que lhe foi fornecido pelo fornecedor subcontratado.
Pgina 9
Captulo 3
3.
3.1
Anlise de Sistemas
Introduo
Por Anlise de Sistemas (AS) entende-se a actividade inicial do processo de desenvolvimento de sistemas em que se determina e especifica o que um sistema deve fazer bem como as circunstncias sob as quais deve operar, envolvendo geralmente um esforo colaborativo entre analistas de sistemas e utilizadores4, no qual os primeiros procuram obter a partir dos segundos, num processo gradual e cumulativo, o maior conhecimento possvel acerca do domnio do discurso do sistema e respectivo ambiente. Actualmente o termo anlise de sistemas por vezes substitudo pelo termo engenharia de requisitos. A adopo do novo nome deve-se preocupao de se pretender incorporar uma orientao de engenharia, adicionando-lhe mais rigor e disciplina. O uso do termo engenharia implica que tcnicas sistemticas e repetveis devam ser usadas para assegurar que os requisitos dos sistemas so relevantes, consistentes e completos.
Os utilizadores so quer os futuros/potenciais utilizadores finais dos SI quer os gestores responsveis pela unidade organizacional onde o SI ser implementado ou clientes que necessitam desenvolver um SI. lvaro Rocha (2008), O Essencial da Anlise de Sistemas. UFP Pgina 10
3.2
Nveis de Interveno da Anlise de Sistemas
No desenvolvimento de sistemas de informao, o desenvolvimento de software ou sistemas informticos ocupa um grande espao. A introduo de um sistema informtico numa situao real de trabalho afecta sempre a estrutura e os arranjos organizacionais, assim como o sistema de informao. Por conseguinte, a Anlise de Sistemas susceptvel de se organizar e intervir em dois nveis principais, tantos quantos os impactes provocados pelos sistemas informticos, como ilustra a figura 3.1. O primeiro - organizacional - diz respeito ao entendimento e definio dos processos bsicos, dados e normas requeridas para atingir o estado desejado da organizao. O segundo - sistema de informao - diz respeito definio de requisitos para um sistema de informao que satisfaa o estado desejado da organizao, sendo a anlise de sistemas de aplicaes ou sistemas informticos uma (sub)-preocupao deste ltima nvel. Do processo de anlise de sistemas devem ento resultar requisitos para sistemas informticos, em consequncia de necessidades detectadas no desenvolvimento do sistema de informao ou na redefinio organizacional.
Anlise de Sistemas
SO SI
SW
SO - Sistema Organizacional SI - Sistema de Informao SW - Software (Sistema Informtico)
Figura 3.1: Componentes e nveis principais da anlise de sistemas.
Pgina 11
3.2
Processo de Anlise de Sistemas
Todo o processo de anlise de sistemas engloba uma teia de sub-processos, sendo muito difcil fazer uma distino clara entre eles. A um nvel de abstraco grande, um processo de anlise de sistemas pode ser descrito como a obteno/definio, anlise e negociao, documentao e validao de requisitos, como ilustra a figura 3.2.
Declarao informal de requisitos

Ponto de deciso: Aceitar documento ou reentrar na espiral
Documento e relatrio de validao dos requisitos
Obteno ou Definio INCIO Validao
Anlise e Negociao Requisitos acordados Documentao
Documento rascunho de requisitos
Figura 3.2: Modelo do processo de anlise de sistemas [adaptado de Kotonya e Sommerville (1998)].
Obteno/definio. Os requisitos dos sistemas so descobertos ou definidos por meio de consultas aos utilizadores, a documentos de sistemas, ao conhecimento do domnio e a estudos de mercado. Carvalho (1996) diz que os requisitos so descobertos ou identificados quando o objectivo unicamente construir sistemas informticos (viso prxima da engenharia de software) e que so definidos quando o objectivo desenvolver o SI (viso de engenharia de sistemas). Tentando explicar melhor, Carvalho afirma que: " Identificar ou descobrir requisitos corresponde a uma postura em que se pressupe que os requisitos existem, "latentes", algures na organizao. Esta atitude compreensvel se atendermos a que o objectivo a construo de um sistema informtico que satisfaa as
necessidades expressas pelos futuros utilizadores do sistema informtico. O sistema informtico um fim em si. Pelo contrrio, definir deliberadamente os requisitos dos sistemas informticos corresponde a uma postura em que os sistemas informticos so vistos como um meio para atingir um fim". Anlise e negociao. Os requisitos so analisados em detalhe e negociados com utilizadores diferentes de modo a decidir quais os requisitos aceitos. Este processo necessrio porque h inevitavelmente conflitos entre requisitos de origens diferentes, a informao pode estar incompleta ou os requisitos expressos podem ser incompatveis com o oramento disponvel para desenvolver o sistema. Usualmente h alguma flexibilidade nos requisitos e necessrio negociar para decidir sobre o conjunto de requisitos a acordar para o sistema. Documentao. Os requisitos acordados so modelados e documentados a um nvel de detalhe apropriado. Geralmente, h a necessidade de ser um documento de requisitos entendido por todos os utilizadores do sistema. Usualmente entende-se que isto deve ser documentado usando linguagem natural e grfica. Validao. Deve ser uma verificao cuidada da coerncia e totalidade dos requisitos. Este processo pretende detectar problemas no documento dos requisitos, antes de ser usado como base nas fases seguintes do desenvolvimento. A figura 3.2 mostra que as diferentes actividades na anlise de sistemas devem ser repetidas at que seja tomada a deciso de aceitao do documento de requisitos. Se for encontrado um problema no rascunho do documento de requisitos, reentra-se na espiral obteno/definio, anlise e negociao, documentao e validao. Isto continua at ser produzido um documento aceitvel ou at factores externos tais como presses de calendarizao ou falta de recursos forarem o trmino do processo de anlise de sistemas. Um documento final de requisitos deve ento ser produzido. Quaisquer mudanas adicionais aos requisitos faro ento parte de um processo de gesto de requisitos. A gesto de requisitos o processo de gesto das mudanas dos requisitos de um sistema. Os requisitos de um sistema mudam sempre como reflexo das mudanas das necessidades dos utilizadores, do ambiente onde o sistema vai funcionar, do negcio, das leis, etc.
3.3
Importncia da Anlise de Sistemas
A anlise de sistemas uma actividade crtica no processo de desenvolvimento de sistemas, por ser uma etapa inicial e cujas falhas tero efeitos em cadeia nas etapas subsequentes assim como no produto final. A determinao incorrecta dos requisitos levar obteno e disponibilizao de sistemas informticos inadequados ao sistema de informao e ao sistema organizacional. Desde h bastante tempo que tem aumentado a conscincia do impacte desta actividade na qualidade/sucesso dos SI, mas os problemas ainda no foram resolvidos. Documentos ou especificaes de requisitos incompletas, pouco claras ou incorrectas provocam dificuldades significativas durante as etapas de desenvolvimento seguintes, levando produo de sistemas com pouca qualidade - por no cumprirem as necessidades reais dos utilizadores - e fora da calendarizao e oramento previstos. De facto, a introduo de falhas no desenvolvimento de sistemas ocorre a maior parte das vezes durante a fase da anlise de sistemas e, importante eliminar estas falhas o mais cedo possvel porque se torna muito mais caro corrigi-las posteriormente. O custo relativo de reparar problemas de requisitos detectados durante a fase de testes finais ou operacionais pode ser 100 vezes superior queles que so detectados durante a fase da anlise de sistemas. Em suma, a determinao dos requisitos parece ser a tarefa mais importante do desenvolvimento de SI, porque a que o problema definido, o mbito da anlise estabelecido e os requisitos de software so alocados. Assim, se a determinao dos requisitos incorrecta o sistema resultante ser incorrecto porque, apesar de podermos chegar a sistemas informticos elegantes, no existir nenhum relacionamento com o que os utilizadores querem ou necessitam. 3.4 Importncia dos Utilizadores
O envolvimento dos utilizadores um tpico crtico em todo o processo de desenvolvimento de sistemas de informao. O seu nvel de participao tem um impacte directo, positivo e significativo na satisfao dos utilizadores. Quanto maior for a sua participao no projecto, maior a sua satisfao como utilizador final.
Pgina 14
No que respeita anlise de sistemas, a participao dos utilizadores aumenta a aceitao do SI pelo desenvolvimento facilitador de expectativas realistas acerca do sistema proposto, aumentando assim a qualidade e o sucesso do sistema pela melhoria do entendimento deste por parte dos utilizadores, fornecendo requisitos mais completos e exactos, evitando o desenvolvimento de um sistema inaceitvel, e fornecendo conhecimento acerca da organizao e processos de negcio que sero suportados pelo sistema. Na anlise de sistemas deve ento haver uma equipa onde, para alm dos analistas de sistemas, esteja tambm presente um grupo representativo de utilizadores, para o problema a resolver, desempenhando um papel activo na determinao dos requisitos. Contudo esta no parece ser a poltica mais seguida na prtica. Um dos pressupostos da AS que tem vindo a ser conduzida por analistas informticos. Estes geralmente nada sabem sobre o negcio. Assim o envolvimento dos utilizadores torna-se ainda mais fundamental. Mas mesmo sendo realizada por analistas de negcio, a sua presena pelo menos til na facilitao futura do processo de negcio. 3.5 Dificuldades na Anlise de Sistemas
A anlise de sistemas deve, como se viu na seco anterior, ser um esforo colaborativo entre analistas de sistemas e utilizadores, onde os primeiros documentam e representam os requisitos usando tcnicas de modelao e ento apresentam as especificaes resultantes aos segundos para as confirmarem. Mas estas tarefas geralmente encontram muitos obstculos. A maior barreira na obteno ou definio de requisitos com qualidade a lacuna de cultura existente entre utilizadores e analistas de sistemas. Duas caractersticas dos analistas de sistemas que contribuem para essa lacuna so: (1) fraco conhecimento do negcio e (2) um ponto de vista de anlise de sistemas excessivamente tcnico/tecnolgico. Como as abordagens tradicionais de anlise de sistemas so desenvolvidas luz destas caractersticas influenciam o processo significativamente.
Pgina 15
Um exemplo de um problema resultante da primeira caracterstica que os requisitos no so entendidos completamente ou podem nunca ser descobertos pelos analistas de sistemas quando o nvel de comunicao entre utilizadores e analistas de sistemas acerca do domnio do discurso baixo. Para a segunda caracterstica, os problemas so: (1) os mtodos e os analistas de sistemas tendem a assumir que os requisitos so completamente conhecidos no incio do processo de anlise de sistemas e que nunca mudam; (2) os utilizadores podem no entender os modelos de requisitos construdos pelos analistas de sistemas, devido a diferenas de pontos de vista entre analistas de sistemas e utilizadores e, ao facto dos modelos serem expressos com notaes de modelao que os utilizadores no simpatizam ou no entendem (isto pode resultar em decises tomadas pelos analistas de sistemas usando os seus modelos, s que os modelos finais do sistema reflectiro a perspectiva dos analistas de sistemas em vez da dos utilizadores); e (3) a pouca ateno prestada ao contexto social e organizacional dentro do qual funciona o sistema, o que levar eventualmente a muitas falhas nos sistemas. As tcnicas tradicionais de obteno de requisitos usadas na prtica geralmente no suportam a natureza colaborativa do processo de anlise de sistemas. Tipicamente envolvem deduo de "factos" por analistas de sistemas acerca dos requisitos dos utilizadores usando uma srie de entrevistas nas quais os utilizadores jogam um papel relativamente passivo e secundrio. Estas tcnicas tambm no suportam adequadamente a natureza emergente dos requisitos, ou seja, nem todos os requisitos so pr-definveis e os utilizadores talvez no conheam as suas necessidades completamente. Os requisitos emergem a partir de interaces entre analistas de sistemas e utilizadores e so refinados ao longo do processo de anlise de sistemas. Mais: estas tcnicas do pouca ateno ao facto do contexto do sistema proposto afectar os requisitos, desenvolvimento e evoluo dos mesmos. O contexto de um sistema o ambiente do mundo real no qual o sistema opera, incluindo a estrutura social e organizacional bem como as pessoas que fazem parte dela.
Pgina 16
Alguns dos constrangimentos referidos podem, todavia, ser ultrapassados pela adopo de mtodos e tcnicas que permitam chegar a melhores modelos, tendo em conta caractersticas tais como: incerteza, volatilidade, contexto e grau de objectividade dos requisitos; valores, crenas, aspectos cognitivos e pontos de vista dos utilizadores; poder, estrutura e cultura organizacional; etc. 3.6 Desenvolvimento de Pontos de Vista
Um dos problemas da definio de requisitos a existncia de requisitos diferentes e conflituosos nos mltiplos utilizadores, dado que cada um tem certas razes para os seus requisitos. Uma das formas de resolver este problema usar o desenvolvimento de pontos de vista. O desenvolvimento de pontos de vista o processo de identificao, compreenso e representao dos diferentes pontos de vista dos mltiplos utilizadores. Isto pode ajudar a que o sistema definido satisfaa as necessidades e expectativas de todos os utilizadores envolvidos pela facilitao do entendimento dos seus vrios pontos de vista e requisitos suportando a gesto de conflitos e inconsistncias entre eles. O conceito de pontos de vista fornece um veculo para discusso, elaborao e refinamento de requisitos, encorajando assim a comunicao e interaco entre os participantes do desenvolvimento. Desta forma harmoniza-se a natureza emergente dos requisitos suportando a elaborao gradual e refinada dos pontos de vista do conhecimento dos requisitos. Metodologias de desenvolvimento de SI tais como a "soft system methodology" (SSM) de Checkland (1981) e a ETHICS5 de Mumford (1983) tm enfatizado a necessidade de explorar e entender diferentes pontos de vista possveis do domnio de um problema. Contudo, o reconhecimento do desenvolvimento de pontos de vista como uma actividade formal e especfica da definio de requisitos relativamente recente. O desenvolvimento explcito de modelos dos pontos de vista dos utilizadores destinado a ajudar a construir um entendimento partilhado de requisitos e do ambiente organizacional no qual um sistema e seus utilizadores coexistem. Isto essencial para o sucesso dos projectos de desenvolvimento de sistemas.
5
ETHICS - Effective Technical and Human Implementation of Computer Based
Pgina 17
Os modelos de pontos de vista dos utilizadores expressam requisitos e perspectivas individuais ou locais. O processo de desenvolvimento de pontos de vista, se envolver todos os utilizadores e usar os seus pontos de vista como um meio de realar a discusso e activar a participao, pode ajudar a dominar como um todo o que se descreve, onde cada grupo de utilizadores entende e assume responsabilidades somente na parte do domnio do problema que lhe diz especificamente respeito, sendo incapaz de avaliar a "imagem" global. Explicitar a modelao de pontos de vista tambm pode levar seleco de uma carteira ptima de necessidades a serem satisfeitas pelo sistema, a qual requer uma focagem de deciso e julgamento de valor centralizado. A integrao de perspectivas e requisitos individuais ou locais num conjunto de requisitos coerente e global pode prosseguir sobre uma base mais informada, se eles forem explorados e bem entendidos (figura 3.3).
Domnio do Discurso
Ponto de Vista A
Ponto de Vista B
Representao e modelao dos diferentes Pontos de Vista
Anlise, Validao e Integrao
Soluo global reconciliada
Figura 3.3: Desenvolvimento e resoluo de pontos de vista.
A base de requisitos ainda pode ser melhorada ao ter-se em conta que diferentes analistas de sistemas tambm podem chegar a diferentes modelos quando modelam o mesmo universo do discurso, o que exige que se preste ateno aos pontos de vista dos diferentes analistas de sistemas de um processo de anlise de sistemas.
Pgina 18
3.7
Vises de Requisitos
As vises de requisitos esto relacionadas com a noo bsica do que constitui ou determina esses mesmos requisitos. Segundo Iivari e Hirschheim (1996) existem trs vises de requisitos possveis: 1. Objectiva. Enfatiza a importncia das caractersticas impessoais tais como a posio organizacional e tarefas do utilizador como um requisito do utilizador determinante, ou a existncia objectiva de poro da realidade a ser modelada. 2. Subjectiva. V os requisitos como sendo primeiramente determinados pelas caractersticas pessoais do utilizador (seus quadros de referncia, estilos cognitivos, etc.). 3. Inter-subjectiva. Enfatiza o voluntarismo no comportamento organizacional e nos requisitos. V em primeiro lugar os requisitos como sendo emergentes e de aceitao social, dependendo estes, portanto, de um senso comum. O conhecimento do mundo social no disponibilizado por meio de meras observaes, mas atravs de interaces com outros. De facto, a partir desta viso, o mundo social no disponibilizado para observao at as interaces ocorrerem. O mundo social emerge de interaces e por isso uma realidade de construo social. A figura 3.4 mostra as relaes das trs vises de requisitos no que respeita ao funcionalismo versus interpretativismo, realismo versus nominalismo, e voluntarismo versus determinismo do comportamento organizacional e em particular do uso de SI. O realismo est associado a processos permanentes e o nominalismo a processos emergentes6. O funcionalismo assume que o comportamento organizacional e o uso de SI so determinados pela estrutura ou processos organizacionais. Por outro lado, o interpretativismo v que a realidade organizacional criada pelas (inter)-aces organizacionais.
A diferena entre processos permanentes e processos emergentes que os primeiros so processos objectivados e relativamente estveis, ao passo que os segundos podem ser vistos maioritariamente como concordncias temporais no continuado processo de negociao e renegociao [Iivari e Hirschheim 1996]. Pgina 19
Interpretativismo
Voluntarismo do comportamento organizacional e uso de SI
Inter subjectiva
Nominalismo Realismo
Subjectiva
Objectiva
Determinismo no comportamento organizacional e uso de SI
Processos emergentes Processos permanentes
Figura 3.4: As trs vises dos requisitos (a) [adaptado de Iivari e Hirschheim (1996)].
A viso objectiva dos requisitos tem uma posio claramente funcionalista; assume que a estrutura e processos organizacionais (a posio e tarefas de um utilizador) definem os seus requisitos, incluindo a sua concepo do domnio do discurso. A viso inter-subjectiva tem por outro lado uma posio claramente interpretativista e enfatiza o voluntarismo no comportamento organizacional e nos requisitos. Os sistemas de informao so vistos como partes integrantes da construo do senso comum da organizao, e o DSI como o desenvolvimento da comunicao organizacional e a formalizao da linguagem profissional da comunidade de utilizadores. Os requisitos so largamente matria de concordncia social. A inter-subjectividade olha em primeiro lugar os requisitos como emergentes7. A viso subjectiva coloca-se entre os dois extremos, funcionalismo e interpretativismo. O molde no contexto da viso subjectiva corresponde concepo dos requisitos em termos de diferentes caractersticas pessoais do utilizador medveis (e.g., estilos cognitivos), visto que o lado interpretativista enfatiza a unicidade e liberdade relacionada com os requisitos de cada utilizador: os seus requisitos so largamente a sua
7
Os requisitos so de natureza emergente dado que emergem de interaces sociais contnuas dos utilizadores nas organizaes [Iivari e Hirschheim 1996]. lvaro Rocha (2008), O Essencial da Anlise de Sistemas. UFP Pgina 20
Funcionalismo
escolha e interpretao pessoal, dependendo de como prefere ver o seu papel organizacional, tarefas, universo do discurso, etc. A figura 3.5 adiciona a dimenso orientao colectiva versus orientao individual ao que foi dito anteriormente. Ela mostra que a viso objectiva e a viso inter-subjectiva tm uma orientao claramente colectiva, ao passo que a viso subjectiva tem uma orientao individual.
Interpretativismo
Inter subjectiva
Orientao colectiva
Subjectiva
Orientao individual
Objectiva
Funcionalismo
Figura 3.5: As trs vises dos requisitos (b) [adaptado de Iivari e Hirschheim (1996)].
Implicaes prticas das trs vises As trs vises tm implicaes prticas importantes na AS. No caso da interpretao objectiva, a anlise de sistemas pode, pelo menos em princpio, ser conduzida como uma actividade impessoal ou anlise realista; a viso subjectiva pressupe a focalizao nas caractersticas e requisitos pessoais de cada utilizador; ao passo que a viso intersubjectiva considera a determinao de requisitos como um papel de anlise e reconstruo social. As trs vises tambm diferem em relao questo da participao dos utilizadores. Pondo de parte argumentos de tica, motivao e execuo na participao dos utilizadores, a viso objectiva pressupe a sua participao quando muito no papel de uma aplicao de domnio especfico: os utilizadores podem ser requeridos para
Pgina 21
explicar as tarefas complicadas suportadas pelo sistema. A participao dos utilizadores benfica at obteno do conhecimento representativo das interligaes do trabalho a ser suportado pelo sistema de informao. No caso da viso subjectiva, os utilizadores podem ser objectos de personalidades de teste diferentes, os resultados derivam do que acreditam que os pode ajudar e do entendimento dos seus requisitos pelo analista de sistemas, ou podem ser um decisor individual, cujos modelos cognitivos e preferncias definem os seus requisitos como dito anteriormente. Finalmente, a viso inter-subjectiva olha os utilizadores como actores integrais da comunicao organizacional cuja participao por definio uma necessidade de modo a conseguirse a inter-subjectividade. Abordagens diferentes de determinao de requisitos diferem claramente nas suas suposies no que respeita s vises dos requisitos, ou na prtica, no so neutras relativamente s diferentes vises. A maioria das abordagens reflecte em primeiro lugar a viso objectiva ou a viso subjectiva. S recentemente, mtodos de anlise de sistemas inspirados em aspectos etnogrficos englobam de algum modo o problema da inter-subjectividade. 3.8 Nveis de Modelao de Requisitos
Quando se definiu DSI disse-se que um processo de mudana que visa melhorar o SI de uma organizao. Essas mudanas podem respeitar quer a sistemas de informao sistematizados (formais), incluindo os baseados em computador, quer a no sistematizados (informais), quer ainda a factores organizacionais, ou seja, sistemas de trabalho/negcio (estrutura hierrquica, arranjos de poder, papeis, procedimentos e processos de trabalho, etc.). Perante esta constatao Iivari (1990) distingue trs grandes nveis na modelao de requisitos: Nvel A: Define o contexto e estrutura organizacional do SI a ser desenvolvido. Nvel B: Define a especificao conceptual do SI. Nvel C: Define a estrutura tcnica do SI. A tabela 3.1 relaciona estes trs nveis de modelao de requisitos com a complexidade, princpio fundamental e grau de originalidade da mudana no SI.
Pgina 22
Tabela 3.1: Nveis de modelao de requisitos versus complexidade, princpio fundamental e grau de mudana no SI [Iivari 1990].
Nveis
A: Organizacional
Complexidade
Quo complexa a mudana organizacional? Nveis hierrquicos, unidades e membros directamente afectados pela mudana. conceptual? N de entidades e tipos de associaes, tipos de transaces, relatrios e consultas, e nmero e complexidade de normas de derivao e dilogo. Quo complexo o modelo tcnico? Nmero e complexidade de programas, bases de dados (ficheiros), controlos de acesso, e a extenso e heterogeneidade do ambiente de software e hardware (sistemas operativos, sistemas de gesto de bases de dados, computadores, redes de comunicao, etc.).
Princpio fundamental
Quo diferentes so as novas estruturas organizacionais e prticas percebidas ou pretendidas? Quo diferente o modelo conceptual percebido ou pretendido?
Originalidade
So as novas estruturas e prticas organizacionais imitadas, adaptadas ou originais? o modelo conceptual imitado, adaptado ou original?
B: Sistema Informao
de Quo complexo o modelo
C: Tcnico
Quo diferente o modelo tcnico percebido ou pretendido?
o modelo tcnico imitado, adaptado ou original?
As mudanas podem, por exemplo, ao nvel organizacional implicar uma mudana nas condies de trabalho, ao nvel do SI implicar a mudana de um modo de interaco offline para um modo de uso on-line, e ao nvel tcnico implicar a mudana de uma base de dados centralizada para uma base de dados distribuda. Os nveis de requisitos de um sistema de informao introduzidos atrs sugerem que os sistemas de informao tm sempre um papel e contexto organizacional especfico (nvel A), independentemente destes serem conscientemente definidos/concebidos ou implicitamente tomados do emaranhamento da estrutura organizacional existente. Existem boas razes para acreditar que este papel deve ser conscientemente concebido e considerado, mesmo tendo em conta as estruturas existentes. Uma dessas razes o facto dos SI no serem somente, ou primariamente, sistemas tcnicos (nvel C), mas serem tambm sistemas sociais e organizacionais (Nvel A), mesmo no caso de se adoptarem pacotes de software.
Pgina 23
Neste documento defende-se que o desenvolvimento e introduo de um sistema informtico numa situao real de trabalho, quer seja desenvolvido internamente ou sub-contratado no exterior ou, ainda, adquirido sobre a forma de um "pacote", afecta sempre a estrutura e arranjos sociais e organizacionais existentes, e por isso necessrio considerar e avaliar sempre esse impacte aquando da anlise e modelao dos sistemas. Actualmente o DSI muitas vezes motivado pela reengenharia/reorganizao dos processos de negcio8 (PNs) ou sistemas de trabalho. Por causa da melhoria ou reengenharia ou simplesmente entendimento dos PNs, Hammer e Champy (1993) consideram essencial comear por descrev-los to exactamente quanto possvel. Um PN pode ser descrito a nveis diferentes, cada nvel correspondendo a tipos diferentes de requisitos de PNs (figura 3.6).
1. Interaces organizacionais
2. Interaces do sistema
Dados
3. Sistema interno
- lista de clientes - informao geogrfica (mapas, grficos, etc.)
Figura 3.6: Nveis de descrio de processos/SI [adaptado de Nurcan et al. (1998)].
Um processo de negcio definido por Hammer e Champy (1993) como um conjunto de actividades que produzem, a partir de uma ou vrias entradas (inputs), um resultado (output) vlido para o cliente. lvaro Rocha (2008), O Essencial da Anlise de Sistemas. UFP Pgina 24
Primeiro, um PN pode ser descrito como um conjunto de interaces entre agentes envolvidos nesse processo (interaces organizacionais). Os agentes podem ser internos ou externos organizao onde os PNs ocorrem (e.g., clientes, fornecedores, operrios, gestores). Tal descrio pode ser completada pela descrio de como um SI suporta, ou deve suportar, se o SI no existir, o PN atravs da descrio de interaces do sistema. Em tais descries, o sistema considerado como um agente. A descrio do PN pode ser completamente refinada e completada pela adio dos requisitos do sistema interno. Em suma, essencial um relacionamento estreito entre o processo que desenvolve o modelo de negcio e o processo que desenvolve o SI. Por conseguinte, considera-se que o desenvolvimento dos trs nveis de descrio deve ser considerado como um todo. 3.9 Tipos de Requisitos
Num processo de anlise de sistemas geralmente reconhecem-se dois grandes tipos de requisitos: i) Funcionais. Descrevem as funes, tarefas e subtarefas que se espera que o sistema realize. Incluem aquelas coisas que os utilizadores e analistas de sistemas esperam que o sistema faa. A identificao e definio de requisitos funcionais no um exerccio de como o sistema suportar as funes, actividades e tarefas, mas sim um exerccio detalhado de como o sistema contemplar e perceber os utilizadores. Os requisitos funcionais geralmente distinguem-se entre orientados aos processos (funes que o sistema deve realizar) e orientados a informao (informao que o sistema deve conter). Na tabela 3.2 apresentamos alguns exemplos de requisitos funcionais, seguindo esta diferenciao.
Pgina 25
Tabela 3.2: Exemplos de requisitos funcionais.
REQUISITOS FUNCIONAIS Orientados a processos
EXEMPLOS O sistema deve permitir que utentes registados consultem o seu histrico clnico. O sistema deve permitir que utentes registados agendem consultas externas. O sistema deve gerar s 24h de cada dia um relatrio com as consultas externas efectuadas por especialidade e por mdico, e disponibiliz-lo ao Director do Servio.
Orientados a informao
O sistema deve guardar num histrico clnico do utente os dados clnicos associados aos seus cuidados de sade. O sistema deve guardar todos os dados contabilsticos associados aos actos de sade prestados aos utentes por um prazo de cinco anos.
No Funcionais. So aqueles requisitos que no dizem especificamente respeito s funcionalidades de um sistema. Eles colocam restries no sistema a desenvolver e no processo a usar, e especificam as restries externas s quais o produto deve obedecer. Requisitos no funcionais incluem, entre outros, requisitos de fiabilidade, segurana, adaptabilidade, portabilidade e desempenho. Por vezes h necessidade de sacrificar requisitos funcionais para respeitar os no funcionais, nomeadamente por limitaes de tecnologia. Os requisitos no funcionais podem ser de mbito geral, por vezes denominados de suplementares, ou estarem associados a um requisito ou sub-conjunto de requisitos funcionais. Na tabela 3.3 apresentamos alguns exemplos de requisitos no funcionais, agrupados por algumas das possveis categorias desses requisitos. Os tipos de requisitos apresentados necessitam de ser identificados e definidos antes de qualquer tarefa de construo de sistemas informticos. Embora isto parea ser indiscutvel, existem ainda muitos profissionais e organizaes que se lanam na sua construo muito antes dos requisitos serem determinados e entendidos.
Pgina 26
Tabela 3.3: Exemplos de requisitos no-funcionais.
REQUISITOS NO FUNCIONAIS Operacionais: o ambiente fsico e tecnolgico no qual o sistema deve operar
EXEMPLOS O sistema deve correr em dispositivos mveis (PDAs e Tablets PCs). O sistema deve integrar-se contabilidade existente. com o sistema de
O sistema deve funcionar em qualquer browser (IE, FireFox, Opera, etc). Desempenho: Velocidade, Cada pgina no dever demorar capacidade, fiabilidade completamente mais do que 4 segundos. a descarregar
O sistema deve estar disponvel para uso 24h por dia, 365 dias por ano. O sistema deve suportar 400 utilizadores em simultneo entre as 9h e as 18h e 200 utilizadores em simultneo nos restantes perodos de tempo. Segurana: Quem est autorizado a aceder ao sistema e sob que circunstncias Somente os Directores de Servio podem aceder aos registos individuais do seu pessoal. Os mdicos somente podero aceder ao histrico clnico dos pacientes dentro da unidade de sade. O sistema deve funcionar num ambiente protegido contra vrus. Culturais e Polticos: Factores culturais e polticos e ainda requisitos legais que afectam o sistema O sistema deve estar preparado para distino entre a moeda Europeia e a dos Estados Unidos da Amrica. A poltica da empresa apenas computadores da marca XPTO. permite adquirir
As cores das interfaces do sistema devem estar alinhadas com as cores base da imagem do SNS. A informao pessoal deve estar protegida de acordo com as normas estabelecidas pela CNPD (Comisso Nacional de Proteco de Dados).
Pgina 27
3.10
Os Analistas de Sistemas
Os analistas de sistemas so os agentes do processo de desenvolvimento de SI que, com a colaborao dos utilizadores, determinam e especificam os requisitos dos sistemas a desenvolver9, desempenhando um papel de facilitador ou de condutor/decisor. Um bom analista de sistemas tem de estar apto a compreender e comunicar um problema completo de forma concisa e ainda a expandir-se em reas especficas quanto as necessrias. Christensen et al. (1996) caracterizam o papel do analista de sistemas em quatro dimenses: i) Aptides. O analista de sistemas tem de estar apto a organizar os requisitos. Os requisitos tm de ser representados como modelos apropriados para uso durante o incio do processo de concepo e serem compreendidos pelos utilizadores. A melhor forma para ganhar estas aptides o analista de sistemas ter experincia em todo o ciclo de vida do desenvolvimento. O analista de sistemas deve ter maturidade suficiente para saber quando deve ser generalista e quando deve ser especfico. s vezes os utilizadores pedem aos analistas de sistemas que provem um requisito como fivel pela descrio da sua implementao. O analista de sistemas maduro deve resistir s presses, enquanto ao mesmo tempo deve satisfazer os utilizadores com comisses de "livros brancos", estudos do negcio e prottipos. ii) Processo. O analista de sistemas tem de saber gerir o refinamento dos requisitos. Muitas vezes, requisitos no controlados arrastam-se, atrasando a concluso do projecto de um sistema para alm do seu trmino previsto. Mesmo que recuse aceitar mudanas de requisitos essenciais, quer para o resultado inicial ou quer para o resultado da manuteno, isso pode resultar no trmino do projecto ou paralisao do negcio. O analista de sistemas tem de estar apto a conduzir o processo completamente, assegurando que o prosseguimento ocorre e que as mudanas so adjudicadas correctamente para satisfao dos utilizadores e restantes desenvolvedores.
As especificaes devem declarar o QUE necessrio, e no COMO deve ser disponibilizado [Hooks 1999a]. lvaro Rocha (2008), O Essencial da Anlise de Sistemas. UFP Pgina 28
iii) Comunicao. O analista de sistemas tem de ser um bom ouvinte, e tem de considerar com imparcialidade tanto opinies tcnicas como no tcnicas. Deve tambm ser um negociador efectivo, mantendo o foco da discusso sobre o fundamental da realidade. Muitas vezes, conflitos de pontos de vista somente podem ser resolvidos atravs de um processo de negociao calculado cuidadosamente, com discusses abertas focadas na tarefa a tratar. Como intermedirio, um analista de sistemas de sucesso tem de comunicar com todas as partes e ser um facilitador da ligao dos diversos pontos de vista. iv) Tecnologia. O analista de sistemas de sucesso deve possuir um entendimento orgnico do domnio do discurso. As coisas e verbos do domnio no devem ser para ele conceitos vagos e abstractos. Para garantir sucesso, um entendimento orgnico tem de ser capturado e modelado num modelo formal e representado numa linguagem formal de requisitos. Esta linguagem deve ser expressa quer em forma de texto quer em forma de notao grfica. O conhecimento do analista de sistemas deve ser multidisciplinar, com uma dessas disciplinas a vir da cincia tradicional, matemtica ou engenharia. Em qualquer caso, o analista de sistemas tem de suplementar as suas aptides gerais de comunicao com aptides matemticas de comunicao para que possa traduzir os requisitos do utilizador numa notao que os construtores possam implementar. De modo a entender todos os requisitos de um SI, o analista de sistemas deve usar um mtodo analtico agnstico, para a situao do problema, e suficientemente flexvel para encontrar diferentes solues, sendo claro que a abordagem a seguir no deve ser tecnicamente rgida. Analista Informtico versus Analista de Negcio Geralmente existem duas interpretaes para o papel de um analista de sistemas. Primeiro, a que se tem tornado num entendimento popular, considera-o predominantemente relacionado com sistemas de computador. A segunda relaciona-o com a resoluo de um problema num contexto lato, menos quantitativo no mtodo e mais orientado anlise de questes polticas estratgicas latas.
Pgina 29
Um analista informtico ou engenheiro de software est interessado na satisfao de uma soluo tecnolgica para um dado problema. Por outro lado, um analista de negcio10 ou engenheiro de negcio est preocupado com uma larga apreciao de um problema e com o contexto no qual ele reside. A crena de que a anlise de sistemas requer o estudo de problemas mal estruturados e ilimitados tanto quanto a engenharia de sistemas baseados em computador como parte da sua interveno, d a ideia de poder existir uma convivncia harmonizada entre engenheiros de negcio/sistemas e engenheiros de software na qual ambos se complementam, o que leva a supor que o ideal seria a mesma pessoa dominar e trabalhar os dois campos. De acordo com a forma como se desenrola a era da informao, o software torna-se mais essencial e complexo, aumentando os pedidos sobre engenheiros de sistemas e de software. Contudo a especializao - especialmente em reas tecnolgicas - isola aqueles que tm habilidades diferentes. Como os projectos falham e se multiplicam os problemas em sistemas crticos, tem de se olhar para as causas de tais imbrglios. Os engenheiros de software esto acostumados a terem os engenheiros de sistemas a fornecer-lhes as mudanas e requisitos alocados ao software. Contudo, demasiado frequentemente, os engenheiros de sistemas trabalham estes aspectos isoladamente sem atrair atempadamente a participao dos engenheiros de software. Ns propomos a criao de equipas de desenvolvimento integradas para reduzir este isolamento. A ideia conseguir que os engenheiros de sistemas e os engenheiros de software trabalhem juntos nos detalhes da definio do sistema e no que o software suposto fazer. O produto ser portanto completado mais rapidamente e ter poucos problemas de interface quando estudado em conjunto. Bate (1998) sugere algumas causas que justificam o surgimento de alguns dos problemas entre analistas informticos e analistas de negcio.
10
Analista de negcio o termo encontrado junto de algumas organizaes [Rocha 1994] para definir o analista de sistemas que se preocupa com a organizao dos processos de negcio/trabalho e com os requisitos a alocar ao software. Por requisitos a alocar ao software entende-se o subconjunto de requisitos do sistema que sero implementados nos componentes de software do sistema. So pessoas que conhecem bem as necessidades do negcio. Pgina 30
O primeiro problema a falta de engenheiros de negcios disponveis com experincia e capacidades apropriadas para trabalhar sobre interfaces (integrao) de software e requisitos. A sua escassez muitas vezes leva a que os analistas informticos tenham de realizar essas tarefas. O segundo problema que os analistas informticos possivelmente tero pouca capacidade e experincia para trabalhar os aspectos dos sistemas do problema e desenvolver uma soluo. Segundo Bate, a necessidade de formao disciplinar transversal evidente j h algum tempo, mas pouco tem sido feito acerca disso. Porqu? Muitos analistas de negcio so seleccionados a partir de disciplinas de hardware e aprendem a ser engenheiros de sistemas no trabalho. A sua experincia em/ou entendimento do desenvolvimento de software muitas vezes demonstra-se inadequado. Por outro lado, muitos analistas informticos no esto habilitados em cincias organizacionais, i.e., a sua formao acadmica e prtica profissional foca-se tipicamente em cincias dos computadores, o que faz com que a definio de requisitos assuma uma nfase tecnolgica, descurando as componentes sociais e organizacionais. Estes dois grupos podem, portanto, ter poucas bases para encorajar trabalho colaborativo. Uma outra razo para a nfase tecnolgica pode ser o facto dos analistas de sistemas acreditarem que a dimenso social, organizacional e poltica difcil de resolver.
Pgina 31
Captulo 4
4. Determinao de Requisitos
4.1 Introduo
Neste captulo apresentamos um conjunto de tcnicas que julgamos serem mais comummente usadas na determinao de requisitos de sistemas de informao, sabendo de antemo que, individualmente, nenhuma consegue satisfazer as diferentes categorias de requisitos. Este conjunto foi determinado pesquisando literatura e usando o conhecimento pessoal. Cada tcnica brevemente discutida e nalguns casos exemplificaremos o seu uso. As tcnicas so apresentadas e discutidas de acordo com as seguintes categorias:
Pgina 32
Observao: observao do comportamento, aprendizagem com o utilizador, prototipagem; Levantamento no-estruturado: entrevistas abertas, "brainstorming"; Mapeamento: "rich pictures", anlise de dados, anlise de decises; Anlise formal: anlise de textos; Levantamento estruturado: entrevistas estruturadas, reutilizao ou padres de requisitos, sesses de JAD (Joint Application Development). 4.2 Tcnicas de Determinao de Requisitos
4.2.1 Tcnicas de observao
Observao do comportamento. Consiste simplesmente em observar (directamente ou por filmagem) os utilizadores no seu ambiente natural de trabalho, enquanto executam tarefas especficas, sem qualquer tipo de interferncia do analista de sistemas. Geralmente envolve o registo de anotaes detalhadas pelo analista de sistemas enquanto observa. A figura 4.1 ilustra as caractersticas da obteno e determinao de requisitos atravs da observao do comportamento.
Observao
10H
Est na hora
Vamos!
Figura 4.1: Determinao de requisitos por observao do comportamento.
Pgina 33
Aprendizagem com o utilizador. O analista de sistemas observa o utilizador no seu posto de trabalho tentando aprender como realizado o trabalho, colocando, sempre que oportuno, questes relacionadas com esse trabalho. Assim o utilizador funciona como um mestre que explica ao aprendiz (analista de sistemas) como se desenrola o trabalho no seu ambiente natural. A figura 4.2 ilustra as caractersticas da obteno e determinao de requisitos atravs da aprendizagem com o utilizador.
Observao
Como faz isso?
Figura 4.2: Obteno e determinao de requisitos atravs de aprendizagem com o utilizador.
Prototipagem. Envolve o desenvolvimento rpido de uma verso piloto executvel ou no de alguma parte ou aspecto de um sistema e suas modificaes subsequentes at ser aprovado pelos utilizadores. Durante a anlise de requisitos, a prototipagem d forma concreta aos requisitos e assiste sua clarificao e determinao. A prototipagem de requisitos pode, por exemplo, consistir na definio dos campos de um formulrio assim como a sua estrutura atravs da simulao numa folha de papel ou qualquer software que o permite, por interaco do analista de sistemas com os utilizadores interessados no sistema em anlise (figura 4.3)
Pgina 34
Figura
4.3:
Obteno
determinao
de
requisitos
atravs
de
prototipagem
[Fonte:
http://interfacematters.com/ ].
As verses dos prottipos desenvolvidas devem ficar registadas na documentao de anlise do sistema, registando-se igualmente as alteraes de requisitos entre verses e quem so os seus responsveis. A figura 4.4 ilustra um exemplo de modelo para o registo da evoluo da prototipagem.
Pgina 35
Formulrio de Avaliao de Prottipo

Nome do Analista: lvaro Rocha Nome do projecto/sistema: Gesto de Pacientes Cdigo do formulrio/ecr: E-5.1 Utilizador 1 Nome do Utilizador Perodo de Anlise Reaces dos Utilizadores Sugestes dos Utilizadores Carlos Manuel 01/09/2007 Utilizador 2 Sofia Galhardo 01/09/2007 Data: 1/09/2007 Entidade/Local: Hospital ABC Verso: 1 Utilizador 3 Utilizador 4
Maioritariamente Excelente! de opinio favorvel Adicionar a DATA do dia da criao ou alterao de dados do paciente Colocar o nmero do ecr no topo para referncia. Adicionar CRIAR ou ACTUALIZAR no ttulo do ecr.
Inovaes Planos de Reviso Introduzir alteraes no dia 30/10/2007. Rever com Carlos e Sofia.
Figura 4.4: Exemplo de formulrio de avaliao de prottipo.
4.2.2 Tcnicas de levantamento no-estruturado
Entrevistas abertas. O analista de sistemas simplesmente discute com o utilizador, sem uma agenda de questes pr-definidas, o domnio do problema e seus requisitos, colocando-o a falar acerca da sua tarefa num ambiente relaxado. A eficcia desta tcnica depende da habilidade de comunicao do analista de sistemas e da capacidade dos utilizadores para estruturarem satisfatoriamente o espao dos seus problemas.
Pgina 36
Os entrevistados normalmente so indicados ao analista de sistemas pela gesto de topo das organizaes ou ento so sugeridos pelo analista quela quando j conhece razoavelmente a realidade em estudo assim como os potenciais entrevistados. As entrevistas devem ser planeadas, podendo adoptar o seu registo um formato como o do exemplo da tabela 4.1.
Nome Santos Lima Posio Director de Servio de Enfermagem Enfermeira Chefe Mdico Propsito da Entrevista Viso estratgica do novo sistema de apoio enfermagem Problemas actuais do sistema de apoio enfermagem Problemas actuais da articulao de informao entre mdicos e enfermeiros Problemas actuais da articulao de informao entre a farmcia e a enfermagem Agendamento 22 de Setembro, 9h-12h 23 de Setembro, 9h-12h 24 de Setembro, 15h-17h 30 de Setembro, 9h-12h
Celeste Reis Carlos Costa
Marina Silva
Farmacutica
Tabela 4.1: Exemplo de planeamento de entrevistas.
Durante as entrevistas os analistas podero realizar o seu trabalho colocando trs tipos de perguntas (tabela 4.2) combinadas com trs nveis de detalhe das mesmas (tabela 4.3).
Tipos de perguntas Fechadas Exemplos Quantos internamentos novos tm por dia? Em que suporte recebem os planos de tratamento dos pacientes internados? Que informao adicional gostaria que o novo sistema proporcionasse? Abertas O que que pensa acerca do sistema de informao actual? Indique alguns dos problemas que enfrenta no seu dia-a-dia de trabalho? Como que decide que tem de aplicar um medicamento a um paciente? Prova Porqu? Pode dar-me um exemplo? Pode explicar-me isso de uma forma um pouco mais detalhada?
Tabela 4.2: Tipos de perguntas.
Pgina 37
Nvel das perguntas Alto Nvel ou muito genricas Mdio Nvel ou moderadamente especficas Baixo Nvel ou muito especficas
Exemplos Como pode ser melhorado o processo de solicitao de medicamentos farmcia hospitalar? Como poderemos reduzir o nmero de devolues de medicamentos farmcia? Como poderemos reduzir o nmero de erros nas solicitaes de medicamentos farmcia?
Tabela 4.3: Nveis das perguntas.
As entrevistas so registadas atravs de notas retiradas pelo analista ou ento filmadas ou gravadas. O analista dever, nos dois ltimos casos, obter autorizao dos entrevistados para efectuar o registo. Aps as entrevistas, o analista dever analisar as notas tiradas ou as filmagens ou gravaes registadas, e elaborar um relatrio devidamente estruturado, onde constem as informaes mais importantes das mesmas. O relatrio de cada entrevista pode seguir uma estrutura como a que se apresenta na figura 4.5.
Pgina 38
RELATRIO de ENTREVISTA
# Entrevista: 2.1 Notas da Entrevista Aprovadas por: lvaro Rocha e Ana Maria Lemos, Analista de Sistemas e Directora de Recursos Humanos Pessoa Entrevistada: Ana Maria Lemos, Directora de Recursos Humanos Entrevistador: lvaro Rocha, Analista de Sistemas Data: 22/10/2007 Objectivo principal: - Entender os relatrios produzidos pelo sistema de Recursos Humanos (RH) actual - Determinar requisitos de informao para o novo sistema Sumrio da entrevista: - Exemplares de relatrios de todos os relatrios do sistema de RH actual seguem em anexo a este relatrio. A informao que no usada ou que est em falta anotada no respectivo relatrio. - Os dois maiores problemas do sistema actual so: -- Os dados dos funcionrios so demasiado antigos (o Departamento de RH necessita de informao at 2 dias antes do final dos meses; actualmente os dados so-lhe fornecidos com 3 semanas de atraso) -- Os dados tm pouca qualidade (muitas vezes os relatrios tm de ser conferidos com as bases de dados do Departamento de RH) -- Os erros mais comuns encontrados no sistema actual incluem informao incorrecta sobre horas de trabalho e falta de informao sobre o salrio mensal. Itens em aberto: - Obter fichas individuais de cada funcionrio junto de Carlos Silva (extenso 1121) - Verificar a forma de calcular os perodos de frias junto de Ana Magalhes - Agendar entrevista com Fernando Peixoto (extenso 1555) para identificar as razes da pouca qualidade dos dados do sistema actual. Notas detalhadas: - Ver transcrio detalhada da entrevista em anexo
Figura 4.5: Estrutura possvel para relatrio de entrevista.
Brainstorming. Facilita a criatividade e resoluo de problemas atravs de encontros de livre gerao de ideias numa situao de grupo. Tem por inteno alargar as fronteiras do espao do problema dos participantes e obter solues no convencionais (pela manipulao de "quadros de experincia" individuais ou definies internas contextuais de eventos e situaes) para permitir aceder a informao e ideias de outra forma indisponveis por causa dos seus "quadros" da situao actual.
Pgina 39
Poder ser, por exemplo, entre outros formatos, um analista de sistemas solicitar a um grupo de trs enfermeiros para descreverem os passos que devem ser dados para que um medicamento esteja disponvel para aplicao a um determinado paciente. Cada um dos enfermeiros pode fazer a descrio solicitada em papel e ao fim de um perodo de tempo pode troc-la com a descrio de outro enfermeiro, de forma que cada um complemente as descries com o que lhe suscitado pela leitura das mesmas. Depois do ciclo de trocas estar concludo, o analista de sistemas ter trs descries, mais completas do que se cada uma delas se limitasse descrio individual de cada um dos enfermeiros.
4.2.3 Tcnicas de mapeamento
Rich pictures. So teis para expressar informalmente um entendimento inicial da situao de um problema (processos, actores, tpicos, ambiente, etc.). Podem representar quer factos "hard", tais como as fronteiras departamentais, actividades e fluxos de informao, quer factos "soft" (informao subjectiva), tais como reas de conflito, tpicos polticos, preocupaes particulares dos utilizadores e papis e normas de comportamento. No existem regras para desenhar Rich Pictures e quaisquer smbolos (mapas, esquemas, cones, etc.) podem ser usados desde que sejam teis e apropriados para a situao. A figura 4.6 apresenta uma Rich Picture para um sistema de ajuda por telefone.
Pgina 40
Figura 4.6: Exemplo de Rich Picture para um sistema de ajuda por telefone. [Fonte: http://systems.open.ac.uk]
Anlise de dados. Esta tcnica assume que os requisitos podem ser determinados adequadamente pela examinao dos fluxos de informao existentes. Assim, os analistas de sistemas analisam formulrios, relatrios e ficheiros (ou bases de dados), bem como outras fontes de informao usadas actualmente, de onde derivam os requisitos de informao dos utilizadores. A anlise de dados pode ser dividida num nmero de tcnicas especficas, incluindo a decomposio de relatrios e formulrios, a qual examina itens existentes para determinar dados de entrada e de processamento, e os diagramas de entidades relacionamentos, os quais do uma noo preliminar da viso e relacionamento de dados e entidades do futuro sistema.
Pgina 41
Figura 4.7: Exemplo de uma factura em papel [fonte: http://www.historia-energia.com].
Figura 4.8: Exemplo de um pequeno Diagrama de Entidades Relacionamentos.
Pgina 42
Anlise de decises. As tcnicas de anlise de decises advogam uma abordagem "topdown" para determinar os requisitos de informao. Estas focam-se nas decises dos utilizadores. Os passos neste processo so: identificar decises; definir algoritmos e processos de deciso; e interpretar necessidades de informao. A anlise de decises composta por um grande conjunto de tcnicas, algumas das quais fazem listas simples enquanto outras constroem modelos interactivos grandes. So exemplos destas tcnicas tabelas e rvores de deciso. Na figura 4.9 apresentamos um exemplo de rvore de deciso.
Figura 4.9: Exemplo de uma rvore de deciso.
4.2.4 Tcnicas de anlise formal
Anlise de textos. usada somente para entender o domnio total do problema. especialmente til para sistemas onde regras e regulamentaes so a norma, tal como em sistemas de leis e impostos. Por exemplo, no caso de um sistema de gesto de recursos humanos, ser necessrio consultar a legislao fiscal para conhecermos as taxas de imposto a aplicar aos funcionrios em funo dos seus rendimentos singulares.
Pgina 43
4.2.5 Tcnicas de levantamento estruturado
Entrevistas estruturadas. a tcnica mais utilizada na obteno de requisitos. Um grande conjunto de tipos de informaes pode ser obtido usando esta tcnica. Envolve a "interrogao" de uma srie de questes estruturadas e pr-definidas ao utilizador. Tanto as entrevista estruturadas como no-estruturadas so estratgias de "interrogao", as quais assumem que os utilizadores tm formas satisfatrias de estruturao do seu entendimento do domnio do problema. So menos comuns em situaes organizacionais complexas, instveis ou mal-estruturadas. A tabela 4.4 e 4.5 apresentam uma estrutura para guia de entrevistas incluindo as perguntas a fazer.
Pgina 44
Guia de Entrevista
Entrevistado: Nome da pessoa a ser entrevistada Local/Meio: Entrevistador: Nome da pessoa que efectuar a entrevista Data:
Escritrio, sala de reunies, nmero de Hora incio: telefone, etc. Hora fim: Objectivos: Alertas: Que dados devem ser obtidos, sobre o que Conhecimento/experincia do entrevistado deve ser obtida concordncia, que reas Opinies conhecida do entrevistado explorar, etc. Agenda: Introduo Conhecimento sobre o projecto Viso geral da entrevista - Tpicos a serem abordados - Permisso para gravar Tpico 1: Perguntas Tpico 2: Perguntas Sumrio dos pontos principais Perguntas do entrevistado Encerramento Observaes gerais: Por exemplo: O entrevistado pareceu muito ocupado. O ideal ser entrevist-lo novamente dentro dos prximos dias para alguns esclarecimentos porque deu apenas respostas curtas. O PC estava desligado, provavelmente no um utilizador regular. Assuntos no resolvidos e tpicos no abordados O entrevistado necessita encontrar um grfico de vendas de 2007. Ele levantou o assunto de como manipular os proveitos das vendas, mas no tivemos tempo de o discutir.
Tabela 4.4: Exemplo de guia de entrevista.
Tempo aproximado 1 minuto 2 minutos 1 minuto
5 minutos 7 minutos 2 minutos 5 minutos 1 minuto
Pgina 45
Guia de entrevista (continuao)

Tpico 1 Perguntas: Pergunta 1 Notas: Resposta
Tem usado o sistema de acompanhamento Sim, solicito um relatrio semanalmente das vendas? sobre a minha linha de produo Se responder sim, ir para a pergunta 2 seno saltar para a pergunta 3 Observao Pareceu-me agitado, talvez sobrestimar a frequncia de uso Pergunta 2 O que gosta menos no sistema? Resposta: As vendas so mostradas em unidades em vez de euros Pergunta 3 Quais as razes para no usar o sistema? Resposta A maioria das funcionalidades que necessito no existe no sistema, conseguindo melhores resultados com recurso ao Excel.
Tabela 4.5: Exemplo de estrutura de perguntas em guia de entrevista.
por
Reutilizao ou padres de requisitos. Consiste em aproveitar requisitos de outros sistemas. Apesar de cada sistema ter requisitos prprios, existe um nmero de situaes onde possivelmente pode ocorrer a reutilizao de requisitos. Sesses de JAD. O JAD (Joint Application Development) uma tcnica de anlise orientada a grupos a qual d importncia a reunies de trabalho estruturadas onde os utilizadores e analistas de sistemas desenvolvem requisitos e especificaes. Requer uma comisso de utilizadores e um lder (analista de sistemas) hbil para facilitar encontros e gerir grupos dinmicos. O JAD expande o mbito da participao do utilizador a um papel representativo, onde os utilizadores articulam, negoceiam e desenvolvem requisitos e especificaes de sistemas colectivamente.
Pgina 46
4.3
Registo dos Requisitos
A forma de registar os requisitos dos sistemas numa estrutura que seja facilmente percebida e simultaneamente facilitadora do trabalho subsequente do processo de desenvolvimento de sistemas de informao no consensual na comunidade de especialistas em anlise de sistemas. Tendo em considerao a nossa viso e sugestes encontradas na literatura, somos adeptos de estruturas prximas das propostas por Raul Wazlawick (2004) e Dennis et al. (2006). Uma combinao destas duas propostas tem merecido a nossa preferncia. Como j tivemos oportunidade de apresentar anteriormente, os requisitos dos sistemas dividem-se em dois grandes grupos: funcionais e no-funcionais. Os requisitos funcionais correspondem listagem de todas as coisas que o sistema deve fazer e os requisitos no-funcionais so restries que se colocam na forma como o sistema deve realizar os requisitos funcionais. Os requisitos funcionais podem ser orientados aos processos ou informao. Os primeiros consistem das funes que o sistema deve realizar e os segundos aos dados que o sistema deve guardar para poder realizar as funes. Os requisitos funcionais derivam-se de eventos externos ao sistema e que o provocam, e de respostas que o sistema deve proporcionar s entidades externas com quem interage. Os requisitos funcionais podem ser classificados como de prioridade Alta, Mdia e Baixa. Classificam-se como prioridade Alta quando os requisitos so bastante importantes para satisfazer os objectivos do sistema; devem ser implementados at ao final do projecto imperativamente. Classificam-se como prioridade Mdia quando so importantes, no entanto se por algum motivo estes requisitos no forem cumpridos parcial ou totalmente, apenas pioram a condio da soluo, mas no comprometem o seu funcionamento. Classificam-se como prioridade Baixa quando so de baixa importncia; so aspectos que podero ser considerados, no entanto, so apenas extras a considerar no caso de haver tempo disponvel para isso.
Pgina 47
J os requisitos no-funcionais podem ser classificados em obrigatrios ou desejveis, e podem estar relacionados com interfaces, implementao, eficincia, tolerncia a falhas, legislao, etc. Os requisitos no-funcionais podem estar associados a requisitos funcionais ou ento serem suplementares, normalmente transversais a parte ou totalidade do sistema. Uma forma simples de registar os requisitos faz-lo numa lista apenas com a classificao de alto nvel, codificao e descrio dos requisitos, como os exemplos da tabela 4.6. Tipos de Requisitos Funcionais Exemplos F11. O sistema deve permitir agendar, alterar e cancelar consultas F12. O sistema deve emitir uma confirmao das consultas agendadas, alteradas e canceladas No-funcionais (associados a funcionais) NF11.1, NF12.1. O agendamento, alterao e cancelamento de consultas deve ser disponibilizado atravs de website na Internet NF12.2 Aps clicar no boto de confirmao, alterao ou cancelamento da consulta, o sistema deve apresentar a confirmao para impresso em menos de 4 segundos. No-funcionais (suplementares) S1. O sistema de gesto de bases de dados deve ser OpenSource, preferencialmente MySQL ou PostgreSQL. S2. As cores de ecrs e formulrios devem estar alinhadas com as cores do Sistema Nacional de Sade.
Tabela 4.6: Exemplo de estrutura simples de registo de requisitos.
Para registo e detalhes de requisitos funcionais, Dennis et al. (2006) sugerem uma estrutura de descrio de cenrio (caso de uso) por cada um dos requisitos funcionais derivados de eventos, tal como o exemplo da tabela 4.7. Neste caso possvel saber a que evento est associado o requisito funcional e ainda quais so os requisitos de informao associados assim como os passos principais. Os requisitos derivados de respostas no devem ser detalhados atravs de cenrio.
Pgina 48
Cenrio/Requisito: Paciente marca, cancela ou altera consulta Prioridade: Alta / Mdia / Baixa
ID: F11
Descrio resumida: Descreve como se marca uma nova consulta bem como se altera ou cancela uma consulta existente. Evento: Paciente apresenta-se ao balco, telefona ou acede ao front-end na Internet, e pede uma nova consulta, ou pede alterao ou cancelamento de uma existente. Tipo: Externo / Temporal Principais Inputs: Descrio Nome e morada do paciente Informao do paciente Facturas por pagar Tipo de consulta Consulta existente Consulta existente Consulta desejada Potenciais consultas Consulta seleccionada Principais passos realizados 1. Paciente contacta a recepo no mbito de uma consulta 2. Paciente fornece o nome e a morada ao Recepcionista 3. Recepcionista valida a existncia do Paciente no Ficheiro de Pacientes. Se for um novo Paciente, o Recepcionista realiza o cenrio Novo Paciente (F10) 4. Recepcionista verifica no Ficheiro de Pacientes se o Paciente tem facturas por pagar. Se o Paciente tem facturas por pagar, encaminhado para a Contabilidade. 5. Recepcionista obtm a aco desejada pelo Paciente (marcar uma nova consulta, alterar ou cancelar uma existente) 5.1 Para alteraes ou cancelamentos, o Recepcionista obtm a data e a hora da consulta existente, encontra a consulta no Ficheiro de Consultas e cancela-a. 5.2 Para nova consulta ou alterao de uma existente, o Recepcionista obtm a data e a hora da consulta desejada e fornece ao Paciente a data e a hora de potenciais consultas at o Paciente seleccionar o momento da consulta. 6. Recepcionista cria uma nova consulta e fornece a confirmao da consulta ao Paciente. Tabela 4.7: Exemplo de cenrio para registo e detalhe de requisito funcional. Nome e morada do paciente Registo do paciente Situao do paciente Facturas do paciente por pagar Tipo de consulta Data e hora de potenciais consultas Consulta cancelada Consulta desejada Potenciais consultas Consulta seleccionada Nova consulta Confirmao da consulta Origem Paciente Fich. Pacientes Fich. Pacientes Paciente Paciente Fich. Consultas Paciente Fich. Consultas Paciente Informao dos passos Principais Outputs: Descrio Situao do paciente Consulta cancelada Potenciais consultas Nova consulta Destino Recepcionista Fich. Consultas Paciente Fich. Consultas
J Wazlawick (2004) sugere uma estrutura para registo e detalhe de requisitos funcionais, registando e classificando na mesma estrutura requisitos no-funcionais associados, tal como o exemplo da tabela 4.8.
Pgina 49
Requisito funcional: Registar emprstimos de vdeos Prioridade: Alta / Mdia / Baixa
ID: F13
Descrio resumida: O sistema deve registar emprstimos de vdeos, indicando o cliente e os vdeos que foram emprestados, bem como a data do emprstimo e valor previsto para pagamento na devoluo. Requisitos no funcionais
Nome Restrio Categoria Desejvel Permanente
NF13.1 Controle de acesso NF13.2 Identificao dos vdeos NF13.3 Identificao do cliente NF13.4 Tempo de registo NF13.5 Janela nica
A funo somente pode ser acedida por utilizadores com perfil de operador ou superior Os vdeos devem ser identificados por um cdigo de barras O cliente dever ser identificado a partir do seu nome e nmero de BI O tempo para registo de cada vdeo deve ser inferior a 1 segundo Todas as funes relacionadas com registo de emprstimos devem ser efectuadas numa nica janela
Segurana
Interface X Interface Desempenho Interface X X X
Tabela 4.8: Exemplo de registo e detalhe de requisito funcional e requisitos no-funcionais associados.
Na tabela 4.9 apresentamos uma proposta, que combina as propostas de Wazlawick (2004) e Dennis et al. (2006), alargando a sua abrangncia e detalhe.
Pgina 50
Cenrio/Requisito funcional: Paciente marca, cancela ou altera consulta Prioridade: Alta / Mdia / Baixa
ID: F11
Descrio resumida: Descreve como se marca uma nova consulta bem como se altera ou cancela uma consulta existente. Evento: Paciente apresenta-se ao balco, telefona ou acede ao front-end na Internet, e pede uma nova consulta, ou pede alterao ou cancelamento de uma existente. Tipo: Externo / Temporal Requisitos no funcionais
Nome Restrio Categoria Desejvel Permanente
NF1.1 Controle de acesso NF1.2 Identificao dos mdicos NF1.3 Identificao do paciente NF1.4 Tempo de registo NF1.5 Janela nica
A funo somente pode ser acedida por utilizadores com perfil de operador ou superior As consultas devem ser identificadas por um nmero e cdigo de barras O paciente dever ser identificado a partir do seu nome e/ou nmero de BI O tempo para registo de cada consulta deve ser inferior a 1 segundo Todas as funes relacionadas com registo de consultas devem ser efectuadas numa nica janela Origem Paciente Fich. Pacientes Fich. Pacientes Paciente Paciente Fich. Consultas Paciente Fich. Consultas Paciente Descrio
Segurana
Interface X Interface Desempenho Interface X X X
Principais Inputs: Descrio Nome e morada do paciente Informao do paciente Facturas por pagar Tipo de consulta Consulta existente Consulta existente Consulta desejada Potenciais consultas Consulta seleccionada
Principais Outputs: Destino Recepcionista Fich. Consultas Paciente Fich. Consultas Situao do paciente Consulta cancelada Potenciais consultas Nova consulta
Pgina 51
Principais passos realizados 1. Paciente contacta a recepo no mbito de uma consulta 2. Paciente fornece o nome e a morada ao Recepcionista 3. Recepcionista valida a existncia do Paciente no Ficheiro de Pacientes. Se for um novo Paciente, o Recepcionista realiza o cenrio Novo Paciente (F10) 4. Recepcionista verifica no Ficheiro de Pacientes se o Paciente tem facturas por pagar. Se o Paciente tem facturas por pagar, encaminhado para a Contabilidade. 5. Recepcionista obtm a aco desejada pelo Paciente (marcar uma nova consulta, alterar ou cancelar uma existente) 5.1 Para alteraes ou cancelamentos, o Recepcionista obtm a data e a hora da consulta existente, encontra a consulta no Ficheiro de Consultas e cancela-a. 5.2 Para nova consulta ou alterao de uma existente, o Recepcionista obtm a data e a hora da consulta desejada e fornece ao Paciente a data e a hora de potenciais consultas at o Paciente seleccionar o momento da consulta. 6. Recepcionista cria uma nova consulta e fornece a confirmao da consulta ao Paciente.
Informao dos passos Nome e morada do paciente Registo do paciente Situao do paciente Facturas do paciente por pagar Tipo de consulta Data e hora de potenciais consultas Consulta cancelada Consulta desejada Potenciais consultas Consulta seleccionada Nova consulta Confirmao da consulta
Tabela 4.9: Exemplo de registo de requisito combinando as duas propostas anteriores.
Uma outra forma de registo e detalhe de requisitos atravs de caso de uso que vem sendo adoptada com alguma frequncia pela comunidade de anlise de sistemas portuguesa, a apresentada na tabela 4.10. Nesta forma so novidades as condies pr e ps, no entanto uma forma limitada no que concerne a requisitos orientados a dados e requisitos no-funcionais. RF 24: Descrio: Consultar livros Esta funcionalidade permite que os utilizadores consultem livros registados previamente no sistema. Os resultados das consultas sero apresentados aos utilizadores. Alta Haver livros registados
Prioridade: Pr-condies:
1. Utilizador indica ISBN, ttulo e/ou autores de livro Sequncia de funcionamento: 2. Utilizador confirma consulta 3. Sistema procura livros que cumpram o/os critrios de consulta. Ps-condies: Os resultados da consulta serem apresentados ao utilizador
Tabela 4.10: Exemplo de registo e detalhe de requisito funcional com condies Pr e Ps.
Pgina 52
Captulo V
5.
Anlise Estruturada
5.1 Introduo A anlise de sistemas envolve o estudo de um sistema com o objectivo de conseguirmos um entendimento completo de como trabalha, quais os seus problemas actuais e quais os seus requisitos. O resultado da anlise de sistemas uma especificao de requisitos para o novo sistema, num nvel de detalhe adequado. A abordagem estruturada para a anlise de sistemas caracterizada pelo uso da decomposio top-down e de tcnicas de modelao dentro de fases discretas definidas no ciclo de desenvolvimento de sistemas de informao.
Pgina 53
De um processo de anlise de sistemas subjacente a um mtodo de anlise estruturada deve resultar um Modelo Essencial ou Lgico que indique o que o sistema deve fazer para satisfazer os requisitos dos utilizadores, mencionando o mnimo possvel (de preferncia nada) sobre como o sistema deve ser construdo e implementado. Devemos pressupor, portanto, que dispomos de tecnologia perfeita e que podemos obter o modelo do sistema a custo zero. Questes sobre como o sistema deve ser construdo e implementado devem ser deixadas para a concepo ou projecto de software. Alguns esforos tm orientado e sustentado a Anlise Estruturada ao longo da sua existncia. Entre eles salientamos as propostas metodolgicas de Gane e Sarson (1986), Yourdon (1992) e ainda do Governo Ingls atravs do seu mtodo SSADM (Downs et al. 1991). So estas, alis, as propostas metodolgicas adoptadas pela ferramenta CASE Visible Analyst11, a qual utilizmos na elaborao de alguns dos diagramas apresentados neste livro. Seguindo a proposta metodolgica de Yourdon (1992), o Modelo Essencial ou Lgico constitui-se de dois sub-modelos (Modelo Ambiental e Modelo Comportamental) e de um Dicionrio de Dados. Modelo Ambiental: Define a fronteira entre o sistema e o seu ambiente externo. Deve ser composto de uma pequena descrio do propsito do sistema, de uma lista de eventos que provocam o sistema, de uma lista de respostas do sistema, de uma lista das entidades externas que interagem com o sistema e ainda de um diagrama de contexto. Modelo Comportamental: Descreve o comportamento do interior do sistema, necessrio para interagir com sucesso com o ambiente. composto por uma descrio detalhada dos propsitos do sistema, diagramas de fluxos de dados, especificaes de processos, diagramas de entidades-relacionamentos e diagramas de transio de estados. Dicionrio de Dados: uma listagem organizada de todos os elementos de dados do sistema, com definies precisas e rigorosas para que os utilizadores e os analistas de sistemas possam reconhecer todas as entradas, sadas, componentes de depsitos de dados e clculos intermdios.
11
http://www.visible.com Pgina 54
5.2 Modelo Ambiental Qualquer sistema que seja desenvolvido, seja ele simples ou complexo, far sempre parte de um sistema maior. Assim, o primeiro modelo a trabalhar na fase de anlise deve ser o modelo ambiental. Este define as interfaces entre o sistema e o resto do universo, ou seja, o ambiente. Modela a parte exterior do sistema. O modelo do interior do sistema ser denominado de modelo comportamental. 5.2.1 Declarao dos Objectivos uma declarao textual concisa e breve dos objectivos do sistema. Uma declarao mais detalhada deve ser deixada para quando do modelo comportamental. Por exemplo: "O propsito do Sistema Mesa de Voto manipular todos os detalhes relacionados
com a votao dos eleitores e a gerao do relatrio de resultados. Informaes sobre eleitores devem estar disponveis para outros sistemas, tal como os sistemas de recenseamento e de atestados e declaraes.".
boa prtica os analistas tambm inserirem na declarao dos objectivos a relao de benefcios tangveis e quantificveis que sero obtidos pelo novo sistema, o que facilitar, no futuro, a avaliao do sucesso do sistema. Por exemplo, a descrio de propsito anterior, ficar mais completa se lhe adicionarmos o seguinte texto:
"O propsito principal do sistema reduzir entre 20% a 40% o tempo de validao dos eleitores bem como a elaborao do relatrio de resultados".
5.2.2 Lista de Eventos Consiste numa lista narrativa dos estmulos que ocorrem no exterior do sistema e aos quais o nosso sistema deve responder. Por exemplo: 1. Eleitor apresenta carto de eleitor (F) 2. Eleitor devolve boletins de voto aps votao (F) 3. Assembleia de voto encerra s 19h (T)
Pgina 55
Cada evento deve ser rotulado com um dos seguintes caracteres: F- quando orientado por um fluxo de dados (chegada de dados) T- quando disparado num determinado momento (Exemplos: Um relatrio
dirio de todos os pedidos de livros solicitado s 9h; As facturas devem ser geradas s 15 horas; Os relatrios para a Direco devem ser gerados a cada hora.
C- um caso especial de evento temporal. So eventos no previsveis. No se relacionam com a passagem normal do tempo. So comuns em sistemas de tempo real. Geralmente no existem em sistemas de gesto tradicionais. Por exemplo, num sistema de controlo do caudal de um rio e respectiva barragem a jusante, o evento Caudal do rio ultrapassa 5 metros de altura (C), um exemplo de um evento de controlo, porque estaria previamente definido que quando o caudal chegasse a essa altura seria necessrio abrir mais as portas de esvaziamento da barragem.
5.2.3 Lista de Respostas Consiste numa lista narrativa das respostas que o sistema deve proporcionar e enviar a entidades externas, em funo dos estmulos que recebe do exterior e do seu papel no sistema maior a que pertence. Exemplos: 1.Boletins de voto so entregues ao Eleitor 2.Carto de eleitor devolvido ao Eleitor 3.Relatrio de resultados enviado Comisso Nacional de Eleies 5.2.4 Construo do Diagrama de Contexto O diagrama de contexto um caso especial de diagrama de fluxos de dados. Um diagrama de contexto compe-se de terminadores (entidades externas), fluxos de dados e um nico processo que representa todo o sistema.
Pgina 56
Processo. a parte mais fcil do diagrama de contexto, consiste de um nico circulo. O nome do processo normalmente o nome do sistema. So exemplos: Sistema de gesto da contabilidade e Sistema de gesto da biblioteca. Terminadores/Entidades Externas. So representados por um rectngulo. Os terminadores comunicam directamente com o sistema atravs de fluxos de dados ou de fluxos de controlo, ou atravs de depsitos de dados externos. Os terminadores no podem comunicar entre si. O diagrama de contexto deve ser construdo de modo que as entradas sejam causadas e iniciadas pelos terminadores e que as sadas/respostas sejam causadas e iniciadas pelo sistema.
Figura 5.1: Diagrama de Contexto para o Sistema Assembleia de Voto.
Pgina 57
5.2.5 Confirmao do Modelo Ambiental O modelo ambiental deve ser confirmado tendo em conta as seguintes verificaes: Cada fluxo de entrada necessrio ao sistema para reconhecer que um evento ocorreu, ou necessrio ao sistema para a produo de uma resposta a um evento, ou ambas? Cada fluxo de sada uma resposta a um ou mais eventos? Cada evento no temporal da lista de eventos tem entradas a partir das quais o sistema pode detectar que o evento ocorreu? Cada evento leva a uma sada imediata como resposta, ou ao armazenamento de dados para serem emitidos como sada posteriormente (como resposta ou parte de resposta a alguma evento), ou faz com que o sistema ou uma sua parte mude de estado? 5.3 Modelo Comportamental Depois de modelado e validado o modelo ambiental necessrio passar para a modelao do comportamento do interior do sistema com recurso a Diagramas de Fluxos de Dados, Diagramas de Entidades Relacionamento e Diagramas de Transio de Estados. 5.3.1 Componentes dos Diagramas de Fluxos de Dados Os Diagramas de Fluxos de Dados (DFDs) so a principal tcnica de modelao funcional da Anlise Estruturada. Estes diagramas modelam o sistema como uma rede de processos ou funes, interligados por fluxos e depsitos de dados. Os Diagramas de Fluxos de Dados so composto de Processos, Fluxos de Dados, Depsitos de Dados e Terminadores/Entidades Externas. Podem ser usados para descrever quer processos computadorizados quer no computadorizados.
Pgina 58
Processos Os processos, tambm conhecidos como funes, representam transformaes de fluxos de dados de entrada em fluxos de dados de sada. Os processos devem ter um nome descritivo do que efectivamente fazem. Geralmente uma aco que provoca uma mudana de estrutura, contedo ou estado. Os processos podem ter representaes grficas circulares ou rectangulares (figura 6.1)
Figura 5.2: Trs notaes para processos.
Fluxos de Dados Os fluxos de dados representam caminhos por onde passam os dados. So representados atravs de setas que indicam o destino dos dados. Tm nomes que devem constar no Dicionrio de Dados (apresentado mais frente). Um mesmo fragmento de dados pode ter significados diferentes em pontos distintos de um DFD (BI-Vlido e BI-Invlido). Um fluxo apenas, no modifica os dados durante o transporte. Os fluxos de dados podem ser transportados entre os seguintes elementos do DFD: Processo a Processo; Entidade Externa a Processo; Depsito de Dados a Processo. E um fluxo de dados pode ser classificado numa de quatro categorias: Fluxo externo: entre Entidade Externa e Processo Fluxo interno: entre dois Processos Fluxo de acesso memria: entre Processo e Depsito de Dados Fluxo de erro ou rejeio: para fora de um Processo
Cada fluxo de dado deve ter um nome nico. O nome deve identificar os dados transportados pelo fluxo (figura 6.2).
Pgina 59
Figura 5.3: Notao para fluxos de dados.
Depsitos de Dados Os Depsitos de Dados representam uma coleco de pacotes de dados em repouso. Importa referir que nem sempre um depsito de dados uma tabela, ficheiro, arquivo ou base de dados. Um depsito de dados, na fase de anlise, pode representar microfilmes, pastas de arquivos em papel e diversas outras formas no computadorizadas. As representaes grficas mais comuns de um depsito de dados so rectangulares e abertas (figura 6.3).
Figura 5.4: Notaes para depsitos de dados.
Os depsitos de dados devem ter um nome no plural. Muitas vezes, este nome pode ser adoptado de nomes de fluxos de dados associados. No entanto, os fluxos de dados entre depsitos de dados e processos nem sempre necessitam ter nome. Quando um pacote de dados recuperado (ou inserido) por completo do depsito de dados, pode-se omitir o rtulo do fluxo de dados correspondente. Entidades Externas ou Terminadores As Entidades Externas (ou Terminadores) so as fontes/destinatrias das informaes que entram/saem do sistema. Os procedimentos executados pelas entidades externas no so especificados no modelo por no fazerem parte do sistema. Normalmente uma pessoa, um grupo de pessoas, uma organizao externa, um sector dentro de uma empresa, ou at um outro sistema. As entidades externas podem ter representaes grficas elpticas ou rectangulares. As entidades externas, como so representadas no Diagrama de Contexto, podero ser omitidas nos Diagramas de Fluxos de Dados subsequentes.
Pgina 60
Figura 5.5: Notaes para entidades externas.
As entidades externas devem ter um nome adequado. Por exemplo: Aluno, Professor, Cliente, etc. para pessoas; Departamento de Marketing, Departamento de Aprovisionamento, Reitoria, Comisso Nacional de Eleies, etc. para seces ou organizaes externas; Sistema de Contabilidade, Sistemas de Vendas, etc., quando se tratar de um sistemas externo.
Figura 5.6: Exemplo de Diagrama de Fluxos de Dados inicial.
Pgina 61
Directrizes para elaborao de DFDs Enumeramos agora algumas directrizes que auxiliam a criao de DFD's com sucesso, ou seja, que evitam a criao de DFD's incorrectos (incompletos ou logicamente inconsistentes) e desagradveis (dificilmente examinados e interpretados pelos utilizadores) Devemos evitar nomes para processos como: Fazer Servio, Manipular Entrada, Cuidar dos Clientes e Processar Dados. Os processos devem ser numerados. A numerao tem basicamente duas utilidades: Permitir localizar os processos no diagrama, facilmente; Facilitar a identificao, a partir dos diagramas mais detalhados, dos processos que so explodidos. No importa a maneira como so numerados os processos, desde que seja consistente. A numerao no indica sequncia, pois o DFD uma rede de processos assncronos que inter-comunicam. Devemos evitar colocar demasiados elementos num diagrama de fluxos de dados. O diagrama deve caber facilmente numa pgina. Este deve modelar correctamente as funes que o sistema deve executar e as interaces entre elas. E deve ser lido e entendido facilmente pelos utilizadores. Um DFD deve ser refeito at que esteja tecnicamente correcto e seja aceite por todos os membros da equipa de desenvolvimento. Os DFDs devem ser esteticamente agradveis. Assim, devemos manter consistentes o tamanho e a forma das bolhas. Decidir adequadamente entre fluxos de dados curvos versus rectos. E optar, sempre que possvel, por diagramas desenhados atravs de aplicaes informticas, preferencialmente ferramentas CASE. Os analistas devem certificar-se de que os DFDs so logicamente consistentes. Assim, devem verificar se h "poos sem fundo" (processos que s recebem entradas), processos com gerao espontnea (processos que no recebem entrada mas produzem sadas), fluxos e processos sem rtulos e depsitos que tenham somente leitura ou escrita.
Pgina 62
De modo a facilitar a elaborao e a leitura dos DFDs devemos ter em ateno a localizao e a ordem de colocao dos seus elementos. Assim, o processo origem deve ficar esquerda ou acima do processo destino, as entidades externas devem ser desenhadas nas bordas dos DFDs (as de entrada, esquerda ou acima; e as de sada, direita ou abaixo). Os depsitos de dados devem ser distribudos no meio do desenho, entre os processos. A duplicao de elementos por vezes til e permitida. Nesse mbito, podem-se duplicar entidades e depsitos para evitar cruzamento de fluxos de dados e melhorar a organizao do diagrama. E um mesmo fluxo de dados pode aparecer mais de uma vez no mesmo DFD. No entanto, no faz sentido duplicar processos. O DFD 0 de sistemas grandes e complexos normalmente necessita ser decomposto para que os modelos do sistema sejam entendidos e passveis de serem mantidos. Para evitar que tudo seja definido num nico diagrama, criam-se DFDs que detalham processos de um nvel mais alto. O diagrama de contexto geralmente considerado como um caso particular de DFD. Neste enquadramento, normalmente visto como o DFD de nvel mais alto. O diagrama de contexto fornece uma viso das ligaes com o ambiente da principal funo do sistema. Contm um processo (representa o sistema), os fluxos externos e as entidades externas O DFD 0 o primeiro DFD na verdadeira acepo do termo. Seguindo o enquadramento dado na seco anterior, pode considerar-se que consiste no detalhamento do diagrama de contexto. O DFD 0 contm as macro-funes do sistema. Os diagramas de fluxos de dados de nveis intermdios so os diagramas que mostram a decomposio (detalhe ou exploso) de cada processo de nvel mais alto. A quantidade de nveis depende de factores como complexidade e dimenso do sistema. Em geral, a decomposio deve terminar quando considerarmos que o processo detalhado j entendido e a especificao do processo possa caber numa pgina.
Pgina 63
5.3.2 Desenvolvimento do Modelo de Processos Depois de modelado e validado o modelo ambiental necessrio passar para a modelao do comportamento do interior do sistema. Geralmente o modelo comportamental segue uma pormenorizao atravs de uma abordagem top-down, mas por vezes, em sistemas complexos, tambm pode haver a necessidade de uma generalizao por meio de uma abordagem bottom-up. A abordagem top-down envolve inicialmente a construo da primeira verso de um Diagrama de Fluxos de Fados (DFD 0), atravs das quatro etapas seguintes: 1. Desenha-se um processo, para cada evento da lista de eventos. 2. Os processos recebem um nmero e ainda um nome, de acordo com a resposta que o sistema deve dar ao evento associado. No caso de um evento Cliente efectua pagamento, um nome adequado para o processo ser, por exemplo, Actualizar contas a receber, em vez de Processar pagamentos de cliente, porque este praticamente no nos diz nada. No devem ser associados processos a pessoas ou sistemas existentes. Assim, devem ser evitados nomes de processos tais como, por exemplo, Joo actualiza contas a receber. 3. Desenham-se entradas e sadas apropriadas de modo que o processo seja capaz de emitir a resposta necessria e desenham-se depsitos de dados, como for mais adequado, para comunicao entre os processos. 4. O DFD resultante inicial verificado em relao ao diagrama de contexto e lista de eventos para que se confirme se est completo e consistente No DFD preliminar (0) no deve haver ligaes entre processos porque eles representam respostas a eventos, sendo difcil que dois eventos ocorram no exterior simultaneamente. O que pode acontecer que haja eventos interdependentes. Nesse caso, o nico modo de os sincronizar atravs de um depsito de dados.
Pgina 64
Figura 5.7: Diagrama de Fluxo de Dados inicial (DFD 0) para o Sistema Assembleia de Voto.
5.3.3 Diagrama de Entidades Relacionamentos O Diagrama de Entidades Relacionamentos (DER) serve para modelar os dados de um sistema. Um DER especifica os dados que so necessrios ao sistema, mostra a quem pertencem os dados e identifica os relacionamentos entre os dados. Entidades Uma Entidade representa uma coleco de objectos ou eventos cujos membros individuais (exemplares ou instncias) tm as seguintes caractersticas:
Pgina 65
Cada um s pode ser identificado de uma nica forma Cada um exerce um papel fundamental no sistema de informao. Cada um pode ser descrito por um ou mais elementos de dados
O nome da entidade deve estar no singular (Exemplos: Cliente, Automvel, Disciplina, Encomenda e Contratao de Funcionrio). Todas as entidades devem estar descritas no Dicionrio de Dados. Relacionamentos Os relacionamentos representam as associaes entre as entidades. Um relacionamento est sujeito existncia das entidades que associa. Os relacionamentos tambm devem estar descritos no Dicionrio de Dados. Tipos de Relacionamentos Os relacionamentos podem ser classificados como no esquema abaixo: Obrigatrios, Opcionais, Mltiplos e Unitrios.
Pgina 66
Figura 5.8: Exemplo de relacionamentos entre entidades.
Classificaes adicionais Entidades fracas ou dependentes: As entidades fracas dependem da existncia de uma ocorrncia da entidade principal. Exemplo: Cliente e Dependente Subtipos e Supertipos: Os Subtipos possuem, alm dos seus atributos especficos, os atributos de seu Supertipo. Exemplo: Cliente, Cliente Pessoa Fsica e Cliente Pessoa Jurdica. Entidades Associativas: So fruto de relacionamentos M para N, ou 1 para N, com informaes prprias. So identificados atravs das chaves das Entidades que relaciona. Exemplo: Produto - Venda - Cliente Cardinalidade A Cardinalidade representa o nmero de ocorrncias de cada entidade associada num relacionamento. Podem ser 1:1 (um para um), 1:N (um para N) e M:N (M para N)
Casos especiais de relacionamentos Relacionamentos entre vrias Entidades Auto-Relacionamento Relacionamento em paralelo
5.3.4 Desenvolvimento do Modelo de Dados Inicial O procedimento de esboar o diagrama de fluxos de dados inicial engloba o desenho de depsitos de dados entre processos assncronos. Na maioria dos casos, a natureza desses depsitos ser bvia e os nomes podero ser escolhidos a partir do conhecimento do objectivo do sistema. Noutros nem por isso. Assim, pode-se desenvolver simultaneamente uma verso inicial do Diagrama de Entidades-Relacionamentos (DER) como uma actividade independente, em paralelo com o desenvolvimento do DFD inicial. Sendo o DFD e o DER desenvolvidos em paralelo podem ser usados para verificaes cruzadas entre eles. Dessa forma, os depsitos que tenham sido definidos experimentalmente no DFD podem ser usados para sugerirem entidades no DER preliminar e vice-versa. Nenhum dos modelos predomina sobre o outro. A lista de eventos to til na elaborao do DER inicial como na do DFD inicial. Os substantivos na lista de eventos muitas vezes mostrar-se-o como entidades no DER. Por exemplo, se um evento for Cliente introduz pedido, identifica-se imediatamente cliente e pedido como entidades experimentais. Podemos usar, do mesmo modo, a lista de eventos como meio de verificao cruzada do DER inicial: todos os tipos de entidades do DER devem corresponder a substantivos na lista de eventos.
Figura 5.9: Diagrama de Entidades Relacionamentos para o Sistema Assembleia de Votos.
Pgina 68
A leitura que se pode fazer do diagrama da figura 6.6 que uma instncia de eleitores, ou seja um eleitor, pode ter registado, num dado momento, zero, um ou mais votos, e que uma instncia de votos pertence a um e um s eleitor. 5.3.5 Como Completar o Modelo de Processos O primeiro passo reorganizar o DFD 0 ou preliminar que pode ser composto de vrios processos. Ento necessrio organizar o DFD em nveis ascendentes. Existem trs directrizes a ter em considerao: 1) Cada agrupamento de processos deve envolver respostas estreitamente relacionadas; 2) Procurar oportunidades para ocultar, ou "sepultar", dados armazenados que apaream no nvel inferior, quando h um grupo de processos no DFD preliminar relativo a um depsito, sem que outros processos se refiram a esse depsito; 3) Cada DFD no deve conter mais do que 7 mais ou menos 2 (ou seja, entre 5 e 9) processos de modo a facilitar a sua leitura. Quando os processos identificados no DFD preliminar no so processos primitivos exigem subdiviso para baixo, em DFDs de nveis inferiores. Isto significa apenas que os processos iniciais, em que cada um dos quais responsvel pela produo da resposta a um evento, podem ser demasiadamente complexos para serem descritos numa especificao de processos. Nalguns casos, a abordagem de decomposio funcional pura adequada. Isto , se encontrar um processo complexo, tente identificar sub-funes, cada uma das quais podendo ser um processo de nvel mais baixo. Noutros casos, os fluxos de dados que chegam e que saem do processo daro melhor indicao para a subdiviso em nveis descendentes. Enquanto estiver envolvido na actividade de subdividir os nveis de maneira ascendente ou descendente lembre-se da importncia do equilbrio. Isto , preciso verificar se as entradas e sadas de um processo de um determinado nvel correspondem s entradas e sadas de um diagrama de nvel imediatamente inferior.
Pgina 69
A seguir apresentamos um diagrama de fluxos de dados de detalhe do processo 1 (DFD 1) e um diagrama de fluxos de dados do processo 3 (DFD 3), presentes no DFD 0. Se pretendermos detalhar o processo 2 o DFD denominar-se de DFD 2.
Figura 5.10: Diagrama de Fluxos de Dados 1 (DFD 1) para o Sistema Assembleia de Votos.
Figura 5.11: Diagrama de Fluxos de Dados 3 (DFD 3) para o Sistema Assembleia de Votos.
Pgina 70
5.3.6 Caracterizao das Entidades em Funo do Tempo No modelo comportamental sugerido at agora, nem os DFDs nem o DERs tm em conta o conceito tempo. Os DFDs especificam os processos que necessitam ser executados pelo sistema de informao. E os DERs fornecem uma viso esttica dos dados que so necessrios execuo desses processos. Assim, necessria uma tcnica que forme uma viso dinmica dos dados pela modelao do efeito que os eventos tm sobre as entidades do DER. Os Diagramas de Transio de Estados (DTEs) definem as mudanas dinmicas que ocorrem na vida de uma entidade. O entendimento de diferentes estados, e as condies que desencadeiam as mudanas de um estado para outro, representam mdulos de operao que devem ser construdos para permitir o sistema funcionar harmoniosamente. Por exemplo, a entidade Encomenda pode ter estados tais como: completa, parcialmente satisfeita, aguarda entrega, em entrega, entregue, perdida, em atraso, devolvida, em dvida, entre outros. Como os estados so posies naturais, e os eventos ou gatilhos aces sobre uma ocorrncia de uma entidade, as transies de um estado para outro representam os mdulos de operao de um sistema. Neste contexto, um evento algo que dispara um processo de alterao de dados do sistema. Um efeito a alterao causada por um evento, tal como criao, eliminao ou modificao de uma ocorrncia de entidade. Um DTE tambm pode ser usado para verificar a consistncia e a totalidade do DFD face ao DER. Isto conseguido pela verificao de que todos os eventos necessrios para criar, modificar e eliminar uma ocorrncia de cada entidade so suportados pelos processos dos DFDs. Abordagem para Construir Diagramas de Transio de Estados Um DTE representa todas as sequncias de eventos que podem ocorrer durante o ciclo de vida de uma ocorrncia de uma entidade no sistema de informao. O primeiro passo na construo de um DTE para uma dada entidade , portanto, identificar todos os eventos que a afectam. Uma tcnica que ajuda este passo a Matriz Eventos/Entidades.
Pgina 71
A Matriz Eventos/Entidades (MEE) uma matriz que lista sobre um eixo as entidades a partir do DER e sobre o outro eixo os eventos que as afectam. Os ltimos so derivados examinando os DFDs e, em particular, os fluxos de dados que escrevem nos depsitos de dados. A MEE mostra que entidades so afectadas por cada evento, e qual dos efeitos consiste em criar, modificar ou eliminar uma ocorrncia de uma entidade. Entidades Eventos Cidado solicita recenseamento Eleitor apresenta carto Eleitor devolve boletins de voto Mudana de morada ou morte C M M E Eleitores
Tabela 5.1: Matriz Eventos-Entidades.
Construo dos DTEs Na construo dos DTEs pode-se seguir duas abordagens: 1. Comear pela identificao de todos os estados possveis da entidade, representando cada um deles como um rectngulo. Em seguida, explorar todas as conexes significativas (e.g., mudanas de estado) entre os rectngulos. 2. Como alternativa, pode-se comear pelo estado inicial, continuando metodicamente o caminho para os estados seguintes; e depois dos estdios secundrios para os tercirios e assim por diante. Verificar correco dos DTEs 1. Foram definidos todos os estados? Examinar cuidadosamente a entidade para verificar se h qualquer outro comportamento observvel ou qualquer outra condio em que a entidade possa estar, para alm daqueles que foram identificados. 2. Todos os estados podem ser atingidos? Algum estado foi definido sem que haja caminhos que levem a ele?
Pgina 72
3. Todos os estados tm sada? Como se disse, o sistema pode ter um ou mais estados finais com mltiplas entradas; mas todos os outros estados devem ter um estado sucessor. Exemplo de DTE Na figura seguinte apresentamos o diagrama de transio de estados para a entidade eleitor.
Figura 5.12: Diagrama de Transio de Estados para a entidade Eleitor.
5.3.7 Especificao de Processos Uma especificao de processo define o que deve ser feito para transformar entradas em sadas. uma descrio detalhada mas concisa da realizao de processos pelos utilizadores. Quando os DFDs estiverem mais ou menos prontos deve-se comear a redigir as especificaes de processos. Este trabalho muitas vezes prolongado porque cada processo do nvel mais baixo do DFD exige uma especificao.
Pgina 73
Os passos lgicos de uma especificao de um processo podem ser mostrados em Linguagem Estruturada, mas por vezes tambm podem ser usadas Condies Pr/Ps, Tabelas de Deciso e rvores de Deciso como alternativas ou complemento das especificaes. Linguagem Estruturada Na linguagem estruturada, os passos lgicos so baseados nas construes base da programao estruturada: sequncia, seleco e iterao. Podem ser usados verbos orientados aco tais como: ADICIONAR SUBTRAIR MULTIPLICAR DIVIDIR CALCULAR MOVER DETERMINAR CRIAR RECUPERAR PROCURAR ORDENAR Exemplo: ACEITAR requisies-armazm RECUPERAR balano-stock EM Stock SUBTRAIR quantidade A balano-stock SE balano-stock < nvel-reposio CRIAR requisio-compra ESCREVER balano-stock EM Stock PR ANOTAR RECEBER SELECCIONAR LER ESCREVER VERIFICAR ELIMINAR VALIDAR SUBSTITUIR
Pgina 74
Condies Pr/Ps So um modo prtico de descrevermos a funo que deve ser executada pelo processo, sem que seja necessrio estendermo-nos muito sobre o algoritmo ou sobre o procedimento que ser empregado. Esta abordagem particularmente til quando: O utilizador tende a expressar o que executada por um processo em termos de um algoritmo especial e particularizado (j conhecido). O analista est razoavelmente seguro de que existem muitos algoritmos que podem ser usados. O analista quer deixar que o programador explore alguns desses algoritmos.
Exemplo: Especificao do Processo 3.5: Calcular Imposto Sobre Vendas Pr-condio 1 DADOS-DE-VENDA ocorre com TIPO-DE-ITEM que CATEGORIA-DE-ITEM em CATEGORIAS de IMPOSTOS Ps-condio 1 TAXA-VENDAS ajustado em TOTAL-VENDAS * VALOR-TAXA Pr-condio 2 DADOS-DE-VENDA ocorre com TIPO-DE-ITEM que no coincide com CATEGORIA-DE-ITEM em CATEGORIAS-DE-IMPOSTOS Ps-condio 2 MENSAGEM-ERRO gerada coincide com
As pr-condies descrevem tudo o que deve ser verdadeiro (se houver algo) antes que o processo inicie o seu funcionamento. As ps-condies descrevem de forma anloga o que deve ser verdadeiro quando o processo terminar a sua tarefa.
Pgina 75
Tabelas de deciso H situaes em que nem a linguagem estruturada e nem as condies pr/ps so adequadas para se elaborar uma especificao de processos. Isso particularmente verdadeiro quando o processo deve produzir alguma sada ou executar aces com base em decises complexas. Como se v no exemplo da figura 5.13, uma tabela de deciso criada relacionando-se todas as variveis relevantes (tambm conhecidas como condies ou entradas) e todas as aces relevantes no lado esquerdo da tabela; observe-se que as variveis e as aces esto separadas por uma linha horizontal dupla. 1 Idade > 65 Sexo Peso > 120 Tratamento 1 Tratamento 2 Tratamento 3 Nenhum tratamento S M S X X X X 2 S M N 3 S F S 4 S F N 5 N M S X X X X X 6 N M N 7 N F S 8 N F N X
Figura 5.13: Uma tabela de deciso tpica verso inicial.
Em seguida, cada combinao possvel de valores das variveis listada numa coluna separada; costume chamar a cada coluna norma. Uma norma descreve a aco (ou aces) que deve ser tomada para uma combinao especfica de valores das variveis. Pelo menos uma aco deve ser especificada para cada norma (isto , para cada coluna vertical na tabela de deciso), ou o comportamento do sistema para aquela situao no ser especificado. Se houver N variveis com valores binrios (verdadeiro/falso), ento haver 2N normas distintas. Os passos resumidos para a construo de tabelas de deciso so:
Pgina 76
1. Identificar todas as condies ou variveis na especificao. Identificar todos os valores que cada varivel pode assumir. 2. Calcular o nmero de combinaes de condies. Se todas as condies forem binrias, haver 2N combinaes de N variveis. 3. Identificar cada aco possvel na especificao. 4. Criar uma tabela de deciso vazia, relacionando todas as condies e aces no lado esquerdo e numerando as combinaes de condies no alto da tabela. 5. Relacionar todas as combinaes de condies, uma para cada coluna vertical da tabela. 6. Examinar cada coluna vertical (norma) e identificar as aces adequadas a serem empreendidas 7. Identificar todas as omisses, contradies e ambiguidades da especificao (ex.: normas da tabela de deciso para as quais a especificao no indique que aces devem ser empreendidas). 8. Discutir as omisses, contradies e ambiguidades com o utilizador. 9. Verificar que normas podero ser suprimidas ou simplificadas. Tabelas de deciso versus rvores de deciso Norma 1 Utilizar uma rvore de deciso quando o nmero de decises for pequeno e nem toda a combinao de condies for possvel; usar uma tabela deciso quando o n. de aces for grande e ocorram muitas combinaes de condies. Norma 2 Utilizar uma tabela de deciso se existirem dvidas de que a rvore de deciso mostra toda a complexidade do problema. Norma 3 Mesmo que necessitemos de uma tabela de deciso para descobrirmos a lgica, procurar represent-la como uma rvore de deciso desde que a Norma 1 no seja violada. 5.4 Dicionrio de Dados O dicionrio de dados , como referido anteriormente, uma listagem organizada de todos os elementos de dados do sistema, com definies precisas e rigorosas para que os utilizadores e os analistas de sistemas possam reconhecer todas as entradas, sadas, componentes de depsitos de dados e clculos intermdios.
Pgina 77
Quando se comea a desenvolver o Diagrama de Contexto, deve-se tambm ter iniciado o desenvolvimento do Dicionrio de Dados. Normalmente faz-se a descrio do significado de cada item de dados presente nos diagramas que desenvolvemos na modelao do sistema. Por uma questo de clareza, pode tambm ser necessrio dividir os itens de dados complexos em sub-itens. Quando o dicionrio de dados estiver a ficar pronto, preciso verificar se ele est consistente e completo. Certifique-se tambm que o dicionrio de dados est equilibrado em relao ao diagrama de fluxos de dados em nveis, ao diagrama de entidades relacionamentos, ao diagrama de transio de estados e s especificaes de processos. Muitas das entradas so constitudas de conjuntos de elementos relacionados. Para este propsito um conjunto de operadores relacionais usado para mostrar estes relacionamentos. O princpio das construes sequncia, seleco e iterao podem ser usadas para processos bem como para dados. Sequncia a concatenao de dois ou mais elementos separados por uma vrgula. Por exemplo: ordem-itens = nome-tipocomida, tipo-comida, preo Seleco a escolha de uma de duas ou mais alternativas mostradas dentro de parnteses recto. Por exemplo: consulta-iten = [pedido-iten | resposta-iten] Iterao a repetio de uma componente zero ou mais vezes mostrada por parntesis curvos. Por exemplo: stock-comida-animal = n-area, {nome-tipo-comida, nvel-stock} Nas seces seguintes apresentamos alguns exemplos adaptados de Robinson e Prior
(1995) para descrio de fluxos de dados, depsitos de dados, elementos de dados e estruturas de dados.
5.4.1 Fluxos de Dados Num dicionrio de dados, um fluxo de dados pode ser definido como um pacote de dados os quais compreendem elementos de dados ou uma combinao dos contedos de outros fluxos e elementos de dados.
Pgina 78
Informao til acerca de um fluxo de dados inclui: Exemplo: Nome: requisito-comida-animal Descrio: Compreende as quantidades dos tipos de comida diferentes requeridos por um animal. Contedo: requisito-comida-animal = quantidade-diria, notas-alimentao} Origem: Guardas Destino: Processo 1.1 Manter Requisitos Comida Animal Volumetria: determinada posteriormente 5.4.2 Depsitos Num dicionrio de dados, um depsito de dados pode ser definido como uma coleco de pacotes de dados. Estes pacotes de dados compreendem um nmero individual de elementos de dados. Informao til acerca de um depsito de dados inclui: Nome; Descrio; Contedo; Fluxos de entrada; Fluxos de sada; Organizao fsica (a ser adicionada na fase de concepo de software). n-animal, n-area, {nome-tipo-comida, Nome; Descrio; Contedo; Origem; Destino; Volumetria.
Pgina 79
Exemplo: Nome: Fornecedores Descrio: Contm os detalhes de cada fornecedor. Contedo: fornecedores = {nome, morada, telefone, fax, {nome-tipo-comida}, descontos} Fluxos de entrada: Nenhum Fluxos de sada: detalhes-fornecedor, detalhes-morada, detalhes-contacto Organizao: Determinada posteriormente 5.4.3 Elementos de dados Um elemento de dados um item de dado significativo que no ser decomposto. Informao til inclui: Nome; Descrio; Aliases (Pseudnimos) - dentro de uma organizao um elemento de dados pode ser referido por nomes diferentes em partes diferentes da organizao; Tipo - usualmente caracter, numrico ou alfanumrico; Formato - formatao do elemento, por exemplo XX9999 significa 2 caracteres seguidos por 4 dgitos numricos; Segurana - autoridade para recuperar/alterar elementos de dados;
A informao seguinte pode ser adicionada durante a concepo de software: Exemplo: Nome: n-animal Descrio: Um nmero nico atribudo a cada animal. Aliases: No 5.4.4 Estruturas de dados Muitas das vezes aquando da criao de um dicionrio de dados, pacotes de dados ou elementos de dados so repetidos dentro de um fluxo de dados ou depsito de dados. Para evitar esta repetio de definio estes elementos de dados podem ser agrupados e definidos como uma estrutura de dados. Informao til inclui:
Pgina 80
Exemplo:
Nome; Descrio; Contedo; Volumetria - se apropriado
Nome: ordem-itens Descrio: uma descrio de cada linha da ordem. Contedo: nome-tipo-comida, requisito-tipo-comida, preo Volumetria: determinada posteriormente
Pgina 81
Captulo V
6.
Anlise Orientada a Objectos
6.1 Introduo As metodologias de anlise orientada a objectos emergiram h cerca de duas dcadas. Estas metodologias procuram sistematizar quer a informao do sistema quer o processamento que manipula essa informao, atravs de objectos do mundo real. Apesar de serem mais recentes do que as metodologias de anlise estruturada, as metodologias de anlise orientada a objectos tm vindo a ganhar terreno quelas, em consequncia do sucesso das linguagens de programao orientada a objectos. Alguns esforos tm orientado e sustentado a anlise orientada a objectos ao longo da sua existncia. Entre eles salientamos as propostas metodolgicas de Coad e Yourdon (1991), Rumbaugh et al. (1991), Jacobson et al. (1991), Martin (1993), Brown (1997) e Dennis et al. (2005). Seguindo a proposta metodolgica de Dennis et al. (2005), de um processo de anlise de sistemas devem resultar trs modelos: Modelo Funcional, Modelo Estrutural e Modelo Comportamental.
Pgina 82
Modelo Funcional. Descreve os processos de negcio e a interaco do sistema de informao com o seu ambiente. Devem ser criados dois tipos de diagramas para descrever a funcionalidade de um sistema de informao: Diagramas de Actividades e Diagramas de Casos de Uso. Os diagramas de actividades suportam a modelao lgica dos processos de negcio e do fluxo de trabalho. Os casos de uso e os respectivos diagramas so usados para descrever as funes bsicas do sistema de informao Modelo Estrutural. Descreve a estrutura dos dados que suportam os processos de negcio nas organizaes. Durante a fase de anlise, o modelo estrutural apresenta a organizao lgica dos dados, sem indicar como os dados so criados, armazenados ou manipulados, uma vez que os analistas devem focar-se no negcio, sem se distrarem com detalhes tcnicos. Mais tarde, durante a fase da concepo ou projecto de software, o modelo estrutural ser actualizado para reflectir como os dados sero armazenados em ficheiros e bases de dados. Modelo Comportamental. Descreve os aspectos da dinmica interna de um sistema de informao. Durante a fase de anlise, o modelo comportamental descreve qual a lgica interna dos processos sem especificar como sero implementados. O modelo comportamental assenta, sobretudo, no desenvolvimento de diagramas de sequncia, diagramas de comunicao e diagramas de transio de estados. 6.2 Modelo Funcional Nesta seco discutimos como a informao sobre os requisitos do sistema, obtida na fase de determinao de requisitos, organizada e apresentada na forma de diagramas de actividades e diagramas de casos de uso. Um diagrama de actividades pode ser usado para modelar qualquer tipo de processo. A modelao de processos mostra como um sistema opera. Com efeito, ilustra as actividades que so realizadas e como os objectos (dados) flem ao longo delas. Um diagrama de casos de uso um modo formal de mostrar como um sistema interage com o seu ambiente. Ilustra as actividades que so realizadas pelos utilizadores do sistema. Como tal, muitas vezes visto como uma viso externa ou funcional do sistema.
Pgina 83
Quer os diagramas de actividades quer os diagramas de casos de uso so modelos lgicos, ou seja, modelos que descrevem as actividades do domnio de negcio em anlise sem sugerirem como elas devem ser conduzidas. Quando algum l um diagrama de actividades ou diagrama de casos de uso na fase de anlise de sistemas, em princpio no saber distinguir se uma dada actividade manual ou computadorizada; se uma dada informao recolhida por formulrio em papel ou via web; se a informao ser colocada numa capa arquivadora ou numa base de dados. Esses detalhes fsicos devem ser definidos na fase da concepo do software, onde os modelos lgicos so refinados em modelos fsicos, ou seja, de construo do software. Analisando a lgica das actividades primeiro, os analistas podem pensar e encontrar a melhor forma do negcio funcionar sem se distrarem com detalhes de implementao. Como primeiro passo da anlise orientada a objectos, os analistas obtm e determinam os requisitos a partir dos utilizadores do sistema. Em segundo lugar modelam o processo de negcio global recorrendo a diagramas de actividades. Em terceiro lugar os analistas usam as actividades identificadas para identificar os casos de uso que ocorrem no negcio e preparam descries de casos de uso e ainda os respectivos diagramas de casos de uso para cada caso de uso identificado. Os casos de uso so as actividades discretas que os utilizadores realizam, tal como, por exemplo, vender um livro (actor vendedor) ou encomendar um livro (actor cliente). Os utilizadores devem trabalhar junta e estreitamente com os analistas para que estes criem bons modelos dos processos do domnio/negcio em anlise, na forma de diagramas de actividades e descries de casos de uso que contm toda a informao necessria para comear a modelar o sistema. Quando os diagramas de actividades e as descries dos casos de uso estiverem preparados, os analistas de sistemas devem transform-los num diagrama de caso de uso que apresenta a viso externa do comportamento ou funcionalidade do sistema (ou processo de negcio) em anlise. O passo seguinte ser os analistas criarem os diagramas de classes com o objectivo de criarem o modelo estrutural do domnio do problema do negcio em anlise.
Pgina 84
6.2.1 Modelao do Processo de Negcio com Diagramas de Actividades Os modelos de processos de negcio descrevem as diferentes actividades que, quando combinadas em conjunto, suportam um processo de negcio. Um processo de negcio normalmente transversal a vrios departamentos (ou reas funcionais). Por exemplo, a criao de um produto novo envolver diversas actividades que combinaro o esforo de vrios empregados de vrios departamentos. Assim, numa perspectiva de anlise orientada a objectos, os processos so transversais a vrios objectos. Um potencial problema na construo dos modelos do processo de negcio, numa perspectiva de anlise orientada a objectos, que tendem a reforar um pensamento de decomposio funcional. Contudo, quando usados adequadamente, so poderosas tcnicas para comunicarem o entendimento dos requisitos dos utilizadores. Os diagramas de actividades so usados para modelar o comportamento associado a um processo de negcio independente dos objectos. Muitas vezes, os diagramas de actividades podem ser vistos como diagramas de fluxos de dados sofisticados das metodologias de anlise estruturada. Contudo, ao contrrio dos diagramas de fluxos de dados, os diagramas de actividades incluem notao que proporciona a modelao de actividades paralelas, concorrentes e processos com decises complexas. Com efeito, os diagramas de actividades podem ser usados para modelar tanto o fluxo de trabalho de alto nvel que envolve diversos casos de uso como para detalhar um s caso de uso. Neste livro restringiremos os diagramas de actividades modelao de alto nvel de processos de negcio.
Tabela 6.1: Elementos e notao dos diagramas de actividades.
ELEMENTO Aco: - uma pea simples de comportamento, no decomponvel; - identificada pelo seu nome. Actividade: - usada para representar um conjunto de aces; - identificada pelo seu nome.
NOTAO
Pgina 85
Objecto N: - usado para representar um objecto que est conectado a um conjunto de Fluxos de Objectos; - identificado pelo seu nome de classe. Fluxo de Controlo: - Mostra a sequncia da execuo. Fluxo de objecto: - Mostra o fluxo de um objecto desde uma actividade (ou aco) para outra actividade (ou aco). N Inicial: - Ilustra o incio de um conjunto de aces ou actividades. N de Actividade Final: - usado para parar todos os fluxos de controlo e fluxos de objecto numa actividade ou aco. N de Fluxo Final: - usado para parar um fluxo de controlo ou fluxo de objecto especfico. N de Deciso: - usado para representar um teste de condio para assegurar que o fluxo de controlo ou fluxo de objecto apenas segue um caminho; - identificado com o critrio de deciso para continuar nesse caminho. N de Fuso: - usado para fundir diferentes caminhos de decises que foram criados usando um n de deciso. N de Desdobramento: - usado para desdobrar o comportamento num conjunto de fluxos de actividades ou aces concorrentes ou paralelas. N de Juno: - usado para juntar um conjunto de fluxos de actividades ou aces paralelas ou concorrentes.
Pgina 86
Pista: - usado para quebrar um diagrama de actividades em linhas e colunas para atribuir actividades ou aces individuais a objectos que so responsveis pela execuo da actividade ou aco.
Na construo de diagramas de actividades devem ser considerados os seguintes passos: 1. Determinar o contexto ou foco do processo a ser modelado de modo a encontrarmos um nome adequado para o diagrama. 2. Identificar as actividades, fluxos de controlo e fluxos de objecto que ocorram entre actividades. 3. Identificar as decises que fazem parte do processo a ser modelado. 4. Identificar eventuais perspectivas de paralelismo no processo. 5. Desenhar o diagrama.
Pgina 87
Figura 6.1: Diagrama de actividades para um sistema de agendamento de consultas.
6.2.2 Descries de Casos de Uso Os casos de uso so descries simples das funes de um sistema a partir das vises e perspectivas dos utilizadores. Os diagramas de casos de uso so diagramas de funes que mostram as funes bsicas do sistema em anlise, ou seja, o que os utilizadores podem fazer e como o sistema deve responder s aces dos mesmos.
Inicialmente os utilizadores devem trabalhar juntamente com os analistas para escreverem as descries dos casos de uso. Depois os analistas devem traduzir estas descries de casos de uso em diagramas de casos de uso formais. Quer as descries de casos de uso quer os diagramas de casos de uso so baseados nos requisitos identificados e nas descries dos diagramas de actividades. Tipos de casos de uso Existem diferentes tipos de casos de uso, tendo em conta o propsito e a quantidade de informao: (1) viso geral versus detalhe; (2) essencial versus real. Um caso de uso de viso geral usado para os analistas e os utilizadores chegarem a um acordo da viso geral dos requisitos de alto nvel. Normalmente so criados no incio do processo de determinao dos requisitos e somente documentam informao bsica acerca do caso de uso, tal como nome, nmero de identificao, actor primrio, tipo e uma breve descrio. Quando os utilizadores e os analistas acordarem a viso geral de alto nvel dos requisitos, o caso de uso de viso geral dever ser convertido num caso de uso de detalhe. Um caso de uso de detalhe normalmente documenta, to detalhadamente quanto possvel, toda a informao necessria para o caso de uso. Um caso de uso essencial aquele que descreve o mnimo essencial necessrio para entender a funcionalidade requerida. Um caso de uso real vai mais alm, descrevendo um conjunto especfico de passos reais. Por exemplo, um caso de uso essencial num consultrio de dentista pode dizer que a recepcionista deve tentar encontrar uma consulta no perodo que o paciente deseja, enquanto que num caso de uso real pode dizer que a recepcionista deve tentar encontrar uma consulta no perodo que o paciente deseja usando o MS Exchange. A principal diferena que o caso de uso essencial independente da implementao, no prescrevendo tecnologia. Assim, os casos de uso reais tendem a ser explorados apenas na fase de concepo dos sistemas de informao.
Pgina 89
Elementos de uma descrio de caso de uso Uma descrio de caso de uso deve conter toda a informao necessria para a construo dos diagramas que se seguem, atravs de uma expresso menos formal, o que simplifica o entendimento pelos utilizadores. As descries de casos de uso devem estruturar-se em trs partes: viso geral, relacionamentos e fluxo de eventos. A tabela 6.2 apresenta um exemplo. Caso de Uso: Marcar consulta Actor Principal: Paciente Interessados: Paciente deseja marcar, cancelar ou alterar uma consulta. Mdico deseja assegurar que as necessidades do paciente sejam satisfeitas atempadamente. Descrio resumida: Este caso de uso descreve como se marca uma nova consulta bem como se altera ou cancela uma consulta existente. Evento: Paciente telefona e pede uma nova consulta, ou pede alterao ou cancelamento de uma existente. Tipo: Externo / Temporal Relacionamentos: Associao: Paciente Inclui: Tratar das questes do pagamento Estende: Criar novo paciente Generalizao: Fluxos de eventos normais: 1. O Paciente contacta o consultrio em relao a uma consulta. 2. O Paciente fornece ao Recepcionista o seu nome morada. 3. O Recepcionista verifica se o Paciente existe na base de dados. 4. O Recepcionista executa o caso de uso Tratar das questes de pagamento. 5. O Recepcionista pergunta ao Paciente se pretende uma nova consulta, ou cancelar ou alterar de uma existente. Se o Paciente deseja marcar uma nova consulta, realizar sub-fluxo S-1. Se o Paciente deseja cancelar uma consulta existente, realizar sub-fluxo S-2. Se o Paciente deseja alterar uma consulta existente, realizar sub-fluxo S-3. 6. O Recepcionista fornece os resultados da transaco ao Paciente. ID: F11 Nvel de Importncia: Alta
Tipo de Caso de Uso: Detalhe, essencial
Pgina 90
Subfluxos S-1 Nova Consulta 1. O Recepcionista pergunta ao Paciente por possveis momentos para a consulta. 2. O Recepcionista tenta encontrar momentos de disponibilidade de consulta coincidentes com os manifestados pelo Paciente e marca a consulta. S-2 Cancelar Consulta 1. O Recepcionista pergunta ao Paciente pelo momento (hora e data) da consulta marcada. 2. O Recepcionista tenta encontrar a consulta marcada no ficheiro de consultas e cancela-a. S-3 Alterar consulta 1. O Recepcionista realiza o Subfluxo S-2 (Cancelar consulta). 2. O Recepcionista realiza o Subfluxo S-1 (Nova consulta). Fluxos alternativos ou de excepo: 3a: O Recepcionista executa o caso de uso Criar novo Paciente. S-1, 2a1: O Recepcionista prope algumas alternativas de momentos de consulta com base na disponibilidade existente na agenda de consultas. S-1, 2a2: O Paciente escolhe um dos momentos propostos ou decide no marcar consulta.
Tabela 6.2: Elementos da descrio de um caso de uso.
Pgina 91
Orientaes para criar descries de casos de uso O essencial de um caso de uso o fluxo de eventos. Escrever o fluxo de eventos de uma forma que seja til para as fases posteriores de desenvolvimento algo que se aperfeioa com a experincia. As boas prticas para a escrita de descries de casos de uso eficazes sugerem que seja observado o seguinte: 1. Sejam escritos na forma da indicao da aco principal que representam. 2. Fique claro quem inicia o passo. 3. Sejam escritos de um forma independente do observador. 4. Cada passo seja escrito com o mesmo nvel de abstraco de todos os demais. 6.2.3 Diagramas de Casos de Uso Um diagrama de caso de uso mostra de uma forma simples as principais funes do sistema em anlise e os diferentes tipos de utilizadores que interagem com o mesmo. Na tabela 6.3 apresentamos os elementos que so usados na criao de diagramas de casos de uso e nas figuras 6.2 (verso inicial) e 6.3 (verso final) apresentamos dois diagramas de casos de uso de um sistema de marcao de consultas de uma clnica. Neles podemos observar que os pacientes, os mdicos e os gestores usam o sistema para marcar consultas, registar a disponibilidade e produzir informao sobre o cronograma, respectivamente.
Pgina 92
Actor: - uma pessoa ou sistema que beneficia do sistema em anlise e externa a este mesmo sistema - ilustrado com uma figura de pessoa ou se no envolve uma pessoa pode ser ilustrado com um rectngulo - designado com o nome do papel que desempenha Pode ser associado a outros especializao/associao de super-classe - colocado no exterior do sistema em anlise Caso de uso: - Representa uma pea importante de funcionalidade do sistema - Pode estender ou caso de uso - Pode incluir outro caso de uso - colocado no interior do sistema em anlise - designado com o nome da aco principal que realiza Fronteira do sistema: - Inclui o nome do sistema no seu interior, na parte superior - Representa o foco da anlise, ou seja, o sistema ou processo de negcio em anlise autores usando a
Relacionamento de Associao: - Liga um actor com um ou vrios casos de uso com os quais interage Relacionamento de incluso: - Representa a incluso da funcionalidade de um caso de uso dentro de outro - A seta desenhada desde o caso de uso base at ao caso de uso includo Relacionamento de extenso: - Representa a extenso do caso de uso para incluir comportamento opcional - A seta desenhada desde o caso de uso de extenso at ao caso de uso base Relacionamento de generalizao - Representa uma especializao de caso de uso para uma maior generalizao deste - A seta desenhada desde o caso de uso de especializao at ao caso de uso de base
Tabela 6.3: Elementos e notao dos diagramas de casos de uso.
Pgina 93
Figura 6.2: Diagrama de Casos de Uso para o Sistema de Marcao de Consultas verso inicial.
Pgina 94
Figura 6.3: Diagrama de Casos de Uso para o Sistema de Marcao de Consultas verso final.
Pgina 95
6.2.4 Passos para escrever boas descries e bons diagramas de casos de uso A seguir enumeramos na tabela 6.4 os passos para escrever boas descries de casos de assim como bons diagramas de casos de uso. 1. Identificar os casos de uso principais: - Rever o diagrama de actividades - Definir a fronteira do sistema - Identificar os actores principais e as suas aces - Identificar os casos de uso principais e escrever a respectiva viso geral - Reviso cuidada dos casos de uso identificados e descritos, tanto quanto o necessrio 2. Expandir os casos de uso principais - Escolher um dos casos de uso para expandir - Iniciar a escrita dos detalhes do caso de uso escolhido - Escrever os fluxos de eventos normais do caso de uso - Se os fluxos de eventos normais forem demasiado complexos ou longos, devem decomp-los em subfluxos - Listar os possveis fluxos excepcionais ou alternativos - Para cada fluxo excepcional ou alternativo, listar como o actor e/ou deve reagir 3. Confirmar os casos de uso principais: - Rever cuidadosamente o conjunto de casos de uso, tanto quanto o necessrio - Inicie no topo novamente 4. Criar o Diagrama - Desenhar a fronteira do sistema - Colocar os casos de uso no diagrama - Colocar os actores no diagrama - Desenhar as associaes
Tabela 6.4: Passos para escrever descries de casos de uso e diagramas de casos de uso.
Pgina 96
6.3 Modelo Estrutural O modelo estrutural descreve a estrutura de dados que suporta as necessidades dos processos de negcio de uma organizao. Durante a fase de anlise, o modelo estrutural apresenta a organizao lgica dos dados sem indicar como os dados sero criados, armazenados ou manipulados, devendo o analista focar-se apenas no negcio sem se distrair com detalhes tcnicos. Mais tarde, na fase de concepo ou projecto de software, o modelo estrutural deve ser actualizado para reflectir como os dados sero armazenados nos ficheiros e bases de dados. O modelo estrutural usualmente retratado usando descries Classes-
Responsabilidades-Colaboraes (CRC), Diagramas de Classes e nalguns casos Diagramas de Objectos. 6.3.1 Classes, Atributos e Operaes Uma classe um modelo que usamos para criar instncias ou objectos especficos, no domnio do sistema. Todos os objectos de uma dada classe so idnticos em estrutura e comportamento mas contm dados diferentes nos seus atributos. Existem dois tipos de classes que interessam durante a fase da anlise: concreta e abstracta. Usualmente, quando os analistas descrevem as classes do domnio do sistema, referem-se a classes concretas, que so usadas para criar objectos. Por outro lado, as classes abstractas so simplesmente abstraces teis. Por exemplo, a partir de uma classe empregado e uma classe cliente, podemos identificar uma generalizao de duas classes e nomear a classe abstracta como classe pessoa. Uma segunda classificao de classes est relacionada com o tipo de coisas do mundo real que representam. Existem classes do domnio do negcio, classes de interfaces do utilizador, classes de estruturas de dados, classes de estruturas de ficheiros, classes de ambientes de operao, classes de documentos e vrios tipos de classes multimdia. Na fase de anlise apenas nos interessam as classes do domnio do negcio.
Pgina 97
Um atributo de uma classe da fase de anlise representa uma pea de informao que relevante para descrio da classe dentro do domnio de negcio em anlise. Um atributo contm informao que os analistas ou utilizadores consideram que o sistema deve guardar. Por exemplo, um atributo possvel e relevante de uma classe empregado ser nome de empregado, ao passo que cor do cabelo do empregado no ser um atributo relevante. Uma operao, ou servio, de uma classe da fase de anlise onde o comportamento da classe definido. Nas fases de desenvolvimento posteriores, as operaes sero convertidas em mtodos. Contudo, e uma vez que os mtodos esto mais relacionados com a construo do software, nesta fase do desenvolvimento usamos o termo operao para descrever as aces s quais as instncias da classe sero capazes de responder. 6.3.2 Relacionamentos Podem ser definidos muitos tipos de relacionamentos, mas todos podem ser classificados dentro de trs categorias bsicas de mecanismos de abstraco de dados: relacionamentos de generalizao, relacionamentos de agregao e relacionamentos de associao. Relacionamento de generalizao A generalizao proporciona aos analistas criar classes que herdam atributos e operaes de outras classes. Os analistas criam superclasses que contm os atributos e operaes bsicas que podem ser usadas em vrias subclasses. As subclasses herdam os atributos e operaes das suas superclasses e tambm podem conter atributos e operaes apenas seus. Por exemplo, a classe cliente e a classe empregado podem ser generalizadas na classe pessoa pela extraco de atributos e operaes que tm em comum e colocando-os numa nova superclasse denominada pessoa. Desta forma, os analistas podem reduzir a redundncia na definio das classes pois os elementos comuns apenas so definidos uma vez, sendo reusados nas subclasses.
Pgina 98
Relacionamento de agregao Os relacionamentos de generalizao so bidireccionais por natureza. Os analistas podem usar a decomposio para partes de uma classe no cobertas que podem ser modeladas separadamente. Por exemplo, se uma porta e um motor so partes de um carro, ento um carro tem as partes porta e motor. Os analistas podem deter-se entre as vrias partes para descobrirem novas partes no consideradas at ento. Por exemplo, os analistas podem perguntar Que outras partes tem o carro? ou A quais outras partes pode a porta pertencer?. Relacionamento de associao Existem outros tipos de relacionamentos que no so cobertos nem pela generalizao nem pela agregao. Por exemplo, um paciente marca uma consulta. Pode ser argumentado que paciente parte de uma consulta. Porm, existe clara diferena semntica entre este tipo de relacionamento e aquele que modela o relacionamento entre portas e carros. Como efeito, apenas considerado como associao entre instncias de classes. 6.3.3 Descries Classes-Responsabilidades-Colaboraes O conjunto de descries Classes-Responsabilidades-Colaboraes (CRC) deve conter toda a informao necessria para construir um modelo estrutural lgico do domnio do problema em anlise. Cada descrio CRC apresenta os elementos essenciais de uma classe. A tabela 6.5 apresenta um exemplo.
Pgina 99
Tabela 6.5: Exemplo de Classes-Responsabilidades-Colaboraes (CRC). Nome da classe: Paciente ID: 3 Tipo: Concreta, domnio Caso de uso associado: 2
Descrio: Um indivduo que necessita receber cuidados de sade Responsabilidades Marcar consulta Determinar ltima consulta Mudar estado Fornecer histrico clnico _____________________________ _____________________________ _____________________________ _____________________________ _____________________________ _____________________________
Colaboradores Consulta _____________________________ _____________________________ Histria clnica _____________________________ _____________________________ _____________________________ _____________________________ _____________________________ _____________________________
Atributos: Valor (duplo) Seguro (texto) _____________________________ _____________________________ _____________________________ _____________________________ Relacionamentos: Generalizao (um tipo de): Agregao ( parte de): Outras Associaes: Pessoa
_____________________________ _____________________________ _____________________________ _____________________________ _____________________________ _____________________________
Histria clnica Consulta
6.3.4 Elementos de um Diagrama e Classes A figura 6.4 apresenta o diagrama de classes para reflectir as classes e os relacionamentos necessrias para os casos de uso do sistema de marcao de consultas. Cada classe desenhada com um rectngulo dividido em trs partes com o nome da classe no topo, os atributos no meio e as operaes no fundo. Por exemplo, podemos identificar Pessoa, Mdico, Paciente, Histria Clnica, Consulta, Factura e Sintoma como algumas das classes do diagrama. Os atributos de uma classe e os seus valores definem o estado de cada objecto que criado a partir da classe, e o comportamento representado pelas operaes.
Pgina 100
Figura 6.4: Diagrama de Classes para o Sistema de Marcao de Consultas.
Os atributos so propriedades da classe sobre os quais pretendemos capturar informao. Notemos que a classe Pessoa contm os atributos nome, morada, telefone e data de nascimento. Por vezes, poderemos pretender guardar em atributos informao derivada de outros atributos, que so atributos calculados ou derivados de outros atributos. O nome dos atributos derivados comea por uma barra antes do nome. Notemos que a classe pessoa contm um atributo derivado, que o atributo /idade, o qual pode ser determinado subtraindo a data de nascimento data actual. Tambm possvel mostrar a visibilidade de um atributo no diagrama de classes. A visibilidade de um atributo pode ser pblica (+), protegida (#) ou privada (-). Um atributo pblico
Pgina 101
aquele que no est escondido para qualquer outro atributo. Com efeito, outros objectos podem alterar o seu valor. Um atributo protegido aquele que est escondido para todas as outras classes excepto para as suas subclasses imediatas. Um atributo privado aquele que est escondido para todas as outras classes. A visibilidade por defeito para um atributo privada. As operaes so aces ou funes que as classes podem realizar. As funes que so comuns a todas as classes (por exemplo: criar uma nova instncia, devolver um valor para um atributo particular, atribuir um valor a um atributo particular, ou eliminar uma instncia) no so mostradas explicitamente dentro do rectngulo das classes. Assim, somente so includas aquelas operaes que so nicas para cada classe, tais como a operao cancelamento sem aviso na classe Consulta e a operao gerar cancelamento de taxa na classe Factura. Tal como nos atributos, a visibilidade de uma operao pode ser designada de pblica, protegida ou privada. A visibilidade por defeito para uma operao pblica. Os diagramas de classes tm como um dos propsitos principais mostrar os relacionamentos, ou associaes, que as classes tm entre elas. Os relacionamentos so mostrados atravs de linhas desenhadas entre classes (figura 6). Quando mltiplas classes partilham um relacionamento, ou uma classe partilha um relacionamento com ela mesma, uma linha desenhada e rotulada com o nome do relacionado ou com o papel que as classes desempenham. Os relacionamentos podem ter multiplicidade, a qual nos indica como uma instncia de um objecto pode estar associada com outras instncias. Nmeros e asteriscos so colocados na linha da associao para mostrar o mnimo e mximo de instncias que podem estar relacionadas atravs da associao no formato nmero mnimo..nmero mximo (ver tabela 6?? ). Por exemplo, 0..1, *, 1..*, 3..5, 1..3-5 No primeiro caso significa que uma instncia da classe oposta est associada com zero ou uma instncia da classe em causa. No segundo caso significa que uma instncia da classe oposta est associada com zero, uma ou vrias instncias da classe em causa. No terceiro caso significa que uma associada da classe oposta est relacionada com uma ou vrias instncias da classe em causa. No quarto caso significa que uma instncia da classe oposta est associada entre trs e cinco instncias da classe em causa. No ltimo caso
Pgina 102
significa que uma instncia da classe oposta est associada entre um e trs ou cinco instncias da classe em causa. Por vezes quando um relacionamento tem propriedades associadas, especialmente quando as suas classes partilham um relacionamento de muitos para muitos, uma nova classe deve ser introduzida, denominada de classe associao, que tem os seus atributos e operaes. representada por um rectngulo ligado ao caminho da associao e a classe deve ter o nome da associao. 6.4 Modelo Comportamental O modelo comportamental descreve os aspectos de dinmica interna de um sistema de informao que suporta processos de negcio numa organizao. Durante a fase de anlise, o modelo comportamental descreve a lgica interna dos processos sem especificar como os processos sero construdos/implementados. Mais tarde, nas fases de concepo e construo, a concepo detalhada das operaes contidas nos objectos completamente especificada. Nesta seco apresentamos trs tipos de diagramas sugeridos pelas metodologias de anlise orientada a objectos para a modelao do comportamento: diagramas de sequncia, diagramas de comunicao e diagramas de transio de estados. 6.4.1 Diagramas de Sequncia Uma das principais diferenas entre os diagramas de classes e os diagramas de interaco (diagramas de sequncia e diagramas de comunicao), para alm das diferenas bvias de que os primeiros descrevem a estrutura e os segundos o comportamento, que o foco da modelao nos diagramas de classes est ao nvel das classes, enquanto o foco dos diagramas de interaco est ao nvel dos objectos. Os diagramas de sequncia so modelos dinmicos que mostram os objectos que participam num caso de uso e a sequncia de mensagens que trocam entre eles ao longo do tempo. O diagrama de sequncia pode ser um diagrama de sequncia genrico que mostra todos os cenrios possveis para um caso de uso.
Pgina 103
Elementos de um Diagrama de Sequncia A figura 6.5 apresenta um diagrama de sequncia que ilustra os objectos e as mensagens para o caso de uso Marcar consulta, o qual descreve o processo pelo qual um paciente marca uma nova consulta, cancela ou altera uma consulta existente no sistema de marcao de consultas. Os objectos que participam na sequncia so colocados ao longo do topo do diagrama usando actores a partir do diagrama de casos de uso e classes a partir do diagrama de classes. No so obrigatoriamente colocados numa dada ordem, embora seja boa ideia organiz-los de uma forma lgica, tal como a ordem em que participam na sequncia. Para cada um dos objectos, o nome da classe da qual so uma instncia deve aparecer depois do objecto. Por exemplo, Pacientes:Lista significa que Pacientes uma instncia da classe Lista que contm objectos de pacientes individuais.
Figura 6.5: Diagrama de Sequncia para o Caso de Uso Marcar Consulta.
Pgina 104
Uma linha tracejada na vertical debaixo de cada actor e objecto mostra a linha de vida de cada actor/objecto ao longo do tempo. Por vezes um objecto cria um objecto temporrio, e neste caso um X colocado no final da linha de vida no ponto em que o objecto destrudo (no mostrado). Por exemplo, num sistema de comrcio electrnico o carrinho de compras usado temporariamente para capturar itens para uma compra, mas quando a compra confirmada, o carrinho de compras no mais necessrio. Neste caso, um X deve ser colocado no ponto em que o carrinho de compras destrudo. Uma caixa rectangular estreita, denominada Execuo de ocorrncia, sobreposta linha de vida para mostrar quando as classes enviam e recebem mensagens (figura 6.5). Uma mensagem uma comunicao entre objectos que transmitem informao na expectativa de que a actividade seja assegurada. Num diagrama de sequncia podem existir diferentes tipos de mensagens. Contudo, no caso de usarmos diagramas de sequncia para modelar casos de uso, dois tipos de mensagens so usualmente usados: mensagens de chamada de operao; e mensagens de retorno. As mensagens de chamada de operao so representadas por uma linha slida com uma seta ligando dois objectos. As mensagens de retorno so representadas por uma linha a tracejado com uma seta. Estas normalmente so omitidas para no sobrecarregar os diagramas. Por vezes uma mensagem enviada somente se uma condio se verificar. Nestes casos uma condio colocada entre parntesis rectos antes da mensagem (e.g., [aPaciente Existe] Encontrar Factura () ). Por vezes uma mensagem repetida. Nestes casos coloca-se um * antes do nome da mensagem. E por vezes um objecto cria outro objecto. Isto mostrado pela mensagem enviada directamente para o objecto que colocado no diagrama apenas na altura em que criado. Na figura 6.5, o actor aRecepcionista cria o objecto anConsulta. Passos na Construo de um Diagrama de Sequncia O primeiro passo na construo de um diagrama de sequncia determinar o seu contexto. O contexto de um diagrama de sequncia pode ser um sistema, um caso de uso ou uma operao de uma classe. A maioria das vezes um caso de uso.
Pgina 105
O segundo passo identificar os objectos que participam na sequncia em modelao, ou seja, os objectos que interagem com cada um dos outros durante um caso de uso. Os objectos so identificados durante o desenvolvimento do modelo estrutural. Estes so as classes sobre as quais os objectos do diagrama de sequncia se basearo. O terceiro passo definir a linha de vida para cada objecto. Para tal, necessitamos desenhar uma linha vertical a tracejado abaixo de cada classe para representar a existncia da classe durante a sequncia. Um X deve ser colocado abaixo do objecto no ponto da linha de vida onde o objecto deixa de existir. O quarto passo consiste em adicionar as mensagens ao diagrama. Para tal desenham-se setas para representar as mensagens que passam de objecto para objecto. As setas devem ser colocadas numa ordem que vai desde a primeira mensagem (no topo) at ltima (no fundo) para mostrar a sequncia temporal. Quaisquer parmetros passados com as mensagens devem ser colocados em parntesis junto ao nome das mensagens. Se uma mensagem deve ser retornada como resposta a uma mensagem, normalmente a mensagem de retorno no mostrada no diagrama. O quinto passo consiste em colocar a ocorrncia de execuo sobre a linha de vida de cada objecto desenhado um rectngulo estreito, que representa quando as classes enviam e recebem mensagens. O sexto e ltimo passo consiste em validar o diagrama de sequncia. O objectivo deste passo garantir que o diagrama de sequncia representa completamente o(s) processo(s) em anlise. Isto feito garantindo que o diagrama representa todos os passos do processo.
Pgina 106
6.4.2 Diagramas de Comunicao Os diagramas de comunicao, tal como os diagramas de sequncia, fornecem essencialmente uma viso dos aspectos dinmicos de um sistema orientado a objectos. Um diagrama de comunicao essencialmente um diagrama de objectos que mostra as mensagens a passar nos relacionamentos em vez de associaes de agregao ou generalizao. Os diagramas de comunicao so teis para mostrar padres de um processo, ou seja, padres de actividades que ocorrem sobre um conjunto de classes que colaboram. Os diagramas de comunicao so equivalentes aos diagramas de sequncia, mas enfatizam o fluxo de mensagens ao longo de um conjunto de objectos, enquanto que os diagramas de sequncia focam-se na ordem temporal das mensagens que so passadas. Portanto, se queremos entender os fluxos de controlo entre um conjunto de objectos, devemos usar um diagrama de comunicao. Se estamos interessados em perceber a ordem temporal das mensagens, devemos usar diagramas de sequncia. Nalguns casos poderemos querer usar ambos para um maior entendimento da actividade dinmica do sistema. 6.4.2 Diagramas de Transio de Estados Algumas classes em diagramas de classes representam um conjunto de objectos que so completamente dinmicos atravessando vrios estados ao longo da sua existncia no sistema. Por exemplo, um paciente pode ao longo do tempo passar por estados tais como dentro, admitido, em observao, em alta (figura 6.7), e por a fora, baseado no seu estado em relao unidade de sade. Um diagrama de transio de estados um modelo dinmico que mostra os diferentes estados que um objecto atravessa ao longo da sua existncia como resposta a eventos. Normalmente, os diagramas de transio de estados no so usados para todos os objectos, mas apenas para objectos complexos, de forma a ajudar a simplificar a concepo de algoritmos para os seus mtodos.
Pgina 107
Figura 6.7: Exemplo de Diagrama de Transio de Estados.
Pgina 108
Bibliografia
Alavi, M., 1984, An assessment of the prototyping approach to information systems developmen,. Communication of the ACM, Vol. 27, n 6, pp. 556-563. Amoako-Gyampah, K. e White, K., 1993, User involvement and user satisfaction: An exploratory contingency model, Information & Management, Vol 25, pp. 1-10. Andriole, S., 1996, Managing Systems Requirements: methods, tools and cases, McGraw-Hill. Avison, D. e Wood-Harper, A., 1990, Multiview: An Exploration in Information Systems Development, Blackwell Scientific Publication. Avison, D. e Wood-Harper, A., 1991, Information systems development research: an exploration of ideas in practice, Computer Journal, Vol. 34, n 2, pp.100-112. Bate, R., 1998, Do systems engineering? Who, me?, IEEE Software, Julho/Agosto, pp. 65-66. Berry, D. e Lawrence, B., 1998, Requirements Engineering, IEEE Software, Maro/Abril, pp. 26-29. Bessa, L., 1997, Buraco Informtico no BPA, Pblico, 15 de Janeiro, p. 31. Beyer, H. e Holtzblatt, K., 1995, Apprenticing with the customer, Communications of the ACM, Vol. 38, n 5, pp. 45-52. Bostrom, R., 1989, Successful application of communication techniques to improve the systems development, Information & Management, Vol. 16, pp. 279-295. Brown, D., 1997, An Introduction to Object-Oriented Analysis, Wiley. Brun-Cottan, F. e Wall, P., 1995, Using video to re-present the user, Communications of the ACM, Vol. 38, n 5, pp. 61-71 Burgess, T., Cossick, K. Zmud, R., 1992, A synthesis of research on requirements analysis and knowledge acquisition techniques, MIS Quarterly, Vol. 16, pp. 117-138. Burn, J., 1993, Effective alignment of information systems and business strategies, Proceedings of the First European Conference on Information Systems, Whitley. Byrd, T., Cossick, K., e Zmud, R., 1992, A synthesis of research on requirements analysis and knowledge acquisitions techniques, MIS Quarterly, Vol. 16, pp. 117-138. Carvalho, J., 1996, Sistemas de Informao e Desenvolvimento de Sistemas de Informao, Cap. 3, Universidade do Minho. CCTA, 1990, Linhas de orientao para o planeamento estratgico de sistemas de informao (traduo do Instituto de Informtica), Informao & Informtica (separata) n 7. Checkland, P. e Poulter, J., 2006, Learning for Action, Wiley. Checkland, P., 1981, Systems Thinking, Systems Practice, Wiley. Chiavenato, I., 1987, Teoria Geral da Administrao, McGraw-Hill.
Christensen, M., 1996, Blueprint for the ideal requirements engineering, IEEE Software, Maro, p. 12. Clavadetscher, C. e Lawrence, B., 1998, User involvement key to success/Designers must do the modelling, IEEE Software, Maro/Abril, p. 30-33. Coad, P. e Yourdon, E., 1991, Object-Oriented Analysis, Second edition, Englewood Cliffs, New Jersey, Yourdon Press. Colter, M., 1984, A comparative examination of systems analysis techniques, MIS Quarterly Vol. 8, n 1, pp. 51-65. Crnkovic, J. e Holstein, W., 1995, Information systems: necessity or luxury in changing economies?, Information Systems Journal, Vol 5, pp. 119-135. Curtis, B., Krasner, H. e Iscoe, N., 1988, A field study of the software design process for large systems. Communication of the ACM, Vol. 31, n 11, pp. 1268-1287. Cysneiros, L. e Leite, J., 1998, Utilizando requisitos no funcionais para anlise de modelos orientados a dados, I Workshop Ibero-Americano de Engenharia de Requisitos, 12 de Outubro de 1998, Maringa, Paran. Darke, P. e Shanks, G., 1997, User viewpoint modeling: understanding and representing user viewpoints during requirement definition, Information Systems Journal, Vol. 8, n 1., pp. 213239. Davis, G., 1982, Strategis for information requirements determination, IBM Systems Journal, Vol. 21, n 1, pp. 4-30. Dennis and Wixom, 2006, System Analysis and Design, 3 ed., John Wiley Dennis, Wixom and Tegarden, 2002, Systems Analysis and Design with UML Version 2.0: An Object-Oriented Approach, 2 ed., John Wiley. Downs, E., Clare, P. e Coe, I., 1992, Structured Systems, Analysis and Design Method: Application and Context, 2 ed., Prentice Hall. Doyle, K., Wood, J. e Wood-Harper, A., 1993, Soft systems and engineering: on the use of conceptual model in information systems development, Journal of Information Systems, Vol. 3, pp. 187-198. Dromey, R., 1996, Cornering the chimera, IEEE Software, January, pp. 33-43. Eriksson, H. e Penker, M., 2000, Business Modeling With UML, Wiley. Finkelstein, A. et al., 1994, Inconsistency handling in multiperspective specifications, IEEE Transactions on Software Engineering, Vol. 20, n 8, pp. 569-578. Fiorini, S., Leite, J. e Lucena, C., 1998, Organizando Processos de Requisitos, I Workshop Ibero-Americano de Engenharia de Requisitos, 12 de Outubro de 1998, Maringa, Paran. Flynn, D. e Jazi, D., 1998, Constructing user requirements: a social process for a social context, Information Systems Journal, Vol. 8, pp. 53-83. Fonseca, P., 1997, Erros, Exame Informtica, n 24, pp. 86-92. Galliers, R., 1991, Choosing information systems research approaches, Warwick Business School. Gane, C, e Sarson, T., 1986, Anlise Estruturada de Sistemas (traduo do original "Structured System Analysis: Tools and Techniques", [1984]), LTC. Gause, D e Weinberg, G., 1989, Exploring requirements: quality before design, John Wiley & Sons. George Marakas, 2001, Systems Analysis and Design: An active approach, 1 ed., Prentice Hall.
Gonalves, V., 1996, A formao de gestores, Expresso, 18 de Janeiro de 1996. Guimaraes, T. e Saraph, J. 1991. The role of prototyping in executive decision systems. Information & Management Vol. 21, n 5, p. 257. Gutierrez, O., 1989, Experimental techniques for information requirements analysis, Information & Management, Vol. 16, pp. 31-34. Hammer, M. e Champy, J., 1993, Re-engineering the corporation: a manifesto for business revolution, Harper Collins publishers. Hammersley, P, 1991, Information systems design methodologies, The Computer Journal, Vol 34, n 2, p 182-185. Hanseth, O. e Monteiro, E., 1996, Navigation future research: judging the relevance of information systems development research, Accounting, Management and Information Technologies, Vol. 6, n 1/2, pp. 77-85. Hepworth, J. et al., 1992, The enhancement of information systems through user involvement in systems design, International Journal of Information Management, Vol 12, p 120-129. Hirschheim, R., Klein, H. e Lyytinen, K., 1996, Exploring intellectual structures of information systems development: a social action theoretic analysis, Accting., Mgmt. & Info. Tech., Vol. 6, n 1/2, pp. 1-64. Hoofer, J., George, J. e Valacich, 2002, Modern Systems Analysis and Design, Third Edition, Prentice Hall. Hooks, Ivy., 1999a, Writing good requirements, Fourth INCOSE Symposium. Hooks, Ivy., 1999b, Management requirements, workpaper. Humphrey, 1989, Managing de Software Process, Addison Wesley. Humphrey, W., 1995, A Discipline for Software Engineering, Addison Wesley. Iivari, J. e Hirschheim, R., 1996, Analysing Information Systems Development: A Comparison and Analysis of Eight IS Development Approaches, Information Systems, Vol. 21, n 7, pp. 551575. IIvari, J., 1990, Implementability of in-house developed vs. aplication package based information systems, Data Base, Spring 1990. Jacobsen, I., 1995, The use-case construct in object-oriented software engineering. In J. M. Carroll (Ed.), Scenario-based design: Envisioning and Technology in System Development. John Wiley & Sons, pp. 309-336. Jacobson, I., Christerson, M., Jonsson, P., Overgaard, G., 1992, Object-Oriented Software Engineering, Addison-Wesley. Jayaratna, N., 1990, Systems analysis: the need for a better understanding, International Journal of Information Management, Vol. 10, pp. 228-234. Jeffrey Hoffer et al., 2002, Modern Systems Analysis and Design, 3 ed., Prentice Hall. Kappel, G. et al., 1996, Web Engineering, Wiley. Kenneth Kendall, Julie Kendall, 2002, Systems Analysis and Design, 5 ed., Prentice Hall. Kotonya, G. e Sommerville, I, 1998, Requirements Engineering: processes and techniques, John Wiley. Leifer, R., Lee, S. e Durgee, J., 1994, Deep Structures: Real information requirements determination, Information & Management, Vol 27, pp. 275-285. Leite, J. e Freeman, P., 1991, Requirements validation through viewpoint resolution, IEEE Transactions on Software Engineering, Vol. 17, n 12, pp. 1253-1269.
Lewis, P., 1993, Identifying cognitive categories: the basis for interpretative data analysis within soft systems methodology, International Journal of Information Management, Vol. 13, p. 373-386. Lyytinen, K., 1987, Different perspectives on information systems: Problems and solutions, ACM Computing Surveys, Vol. 19, n. 1, pp. 5-46. Mahmood, M., 1987, System development methods - a comparative investigation. MIS Quarterly Vol. 11, n 3, pp. 293-312. Mansell, G., 1991, Action research in information systems development, Journal of Information Systems, Vol. 1, pp. 29-40. Martin, J, 1991, Engenharia da Informao: Introduo (traduo do original Information Engineering: Introduction [1989]), Campus. Martin, J., 1993, Object-Oriented Analysis and Design, Prentice-Hall. Mathiassen, L., 1996, Information systems development: reflections on a discipline, Accounting, Management and Information Technologies, Vol. 6, n 1/2, pp. 115-125. Mumford, E., 1983, Designing Human Systems. MBS Press Mumford, E., 1985, Defining system requirements to meet business needs: a case study example, The Computer Journal, Vol. 28, 97-104. Mumford, E., 1986, Using computer for business success: the ETHICS method, MBS Press. Munro, M. e Davis, G., 1977, Determining management information needs: A comparison of methods, MIS Quarterly, pp. 55-67. Necco, C., Gordon, C. e Tsai, N., 1987, Systems analysis and design: current practices, MIS Quarterly Vol. 11, n 4, pp. 461-475. Nidumolu, S., 1996, Standardization, requirements uncertainty and software project performance, Information & Management, Vol. 31, n 3, pp. 135-150. Nissen, H. et al., 1996, Managing multiple requirements perspectives with metamodels, IEEE Software, Maro, pp. 37-48. Nurcan, S., Grosz, G. e Souveyet, C., 1998, Describing business processes with a guided use case approach, Crews Report 98-4. Nuseibeh, B., Kramer, J. e Finkelstein, A., 1994, A framework for expressing the relationships between multiple views in requirements specifications, IEEE Transactions on Software Engineering, Vol. 20, n 10, pp. 760-773. Palvia, P. e Nosek, J., 1993, A field examination of system life cycle techniques and methodologies, Information & Management Vol. 25, pp. 73-83. Poulymenakou, A. e Holmes, A., 1996, A contingency framework for the investigation of information systems failure, European Journal of Information Systems, Vol. 5, n 1, pp. 34-46. Pressman, R., 1997, Software Engineering: a practitioners approach, 4 ed., McGrawHill. Purvis, R. e Sambamurthy, V., 1997, An examination of designer and user perceptions of JAD and the traditional IS design methodology, Information & Management, Vol. 32, n 3, pp. 123135. Ramos, J., 1997, A nova era da programao, Expresso, Caderno XXI, 5 de Julho, p. 10. Ral Wazlawick, 2004, Anlise e Projecto de Sistemas de Informao Orientados a Objectos, Editora Campus. Robertson and Robertson, 1999, Mastering Requirements Process, Addison-Wesley.
Pgina 112
Robey, D e Newman, M., 1996, Sequential patterns in information systems development: an aplication of social process model, ACM Transactions on Information Systems, Vol. 14, n. 1, pp. 30-63. Robinson, B. e Prior, M., 1995, Systems Analysis Techniques, International Thomson Computer Press. Rocha, A., 1994, Desenvolvimento de Sistemas de Informao: Estudo sobre a sua conduo nas organizaes, Dissertao de Mestrado, Universidade Catlica Portuguesa. Rocha, A., 2000, Influncia da Maturidade da Funo Sistemas de Informao na Abordagem Engenharia de Requisitos, Tese de Doutoramento, Universidade do Minho. Roques, P., 2004, UML in Practice, Wiley. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., Lorensen, W., 1991, Object-Oriented Modeling and Design, Prentice-Hall. Saarinen, T., 1990, System development methodology and project success: an assessment of situational approaches, Information & Management Vol. 19, n 3, pp. 61. Saarinen, T., 1996, An expand instrument for evaluating information systems success, Information & Management, Vol. 31, n 2, pp. 103-118. Satriani, G., 1996, Improving the Software Development Process, European Software Institute, EOQ-9602-01. SEI, 1991, Requirements Engineering and Analysis Workshop Proceedings, Software Engineering Institute, Technical Report, CMU/SEI-91-TR-30, ESD-TR-91-30. Shemer, I., 1987, Systems analysis: a systemic analysis of a conceptual model, Communications of the ACM, Vol. 30, n 6. Siddiqi, J., 1996, Requirements Engineering: the emerging wisdom, IEEE Software, Maro, pp. 15-19. Sillince, J. e Harindranath, G., 1998, Integration of requirements determination and business process re-engineering: a case study of an Ambulatory Care and Diagnostic (ACAD) centre, European Journal of Information Systems, Vol. 7, n 2, pp. 115-122. Silva, A. e Videira, C., 2005, UML - Metodologias e Ferramentas CASE - 2 Edio - Volume 1, CentroAtlntico. Sommerville, I. e Sawyer, P., 1997, Requirements Engineering: a good practice guide, John Wiley & Sons. Stephen Schach, 2002, Object-Oriented and Classical Software Engineering, McGrawHill. Stowell, F., 1991, Towards client-led development of information systems, Journal of Information Systems, Vol. 1, pp. 173-189. Sutcliffe, A. e Minocha, S., 1998, Linking business modeling to socio-technical system design, CREWS Report 98-35. Teng, J. e Sethi, V., 1990, A comparison of information requirements analysis methods: An exeperimental study, Data Base, Winter 1990, pp. 27-39. VA, 2000, Tutorial on Structured Methods and the Repository, Visible Systems Corporation. Vidgen et al., 2002, Developing Web Information Systems, Butterworth-Heinemann. Vidgen, R., 1997, Stakeholders, soft systems and technology: separation and mediation in the analysis of information systems requirements, Information Systems Journal, Vol. 7, n 1, pp. 2146.
Pgina 113
Vitalari, N., 1985, Knowledge as a basis for expertise in systems analysis: an empirical study, MIS Quarterly, Vol 9, n 3, pp. 221-241. Walsham, G., 1996, Exploring the intellectual structures of information systems development: a short critique, Accounting, Management and Information Technologies, Vol. 6, n 1/2, pp. 133138. Wiel, S. e Votta, L., 1993, Assessing software designs using capture-recapture methods, IEEE Transactions on Software Engineering, Vol. 19, n 11, pp. 1045-1054. Winter, M., Brown, D. e Checkland, P., 1995, A role for systems methodology in information systems development, European Journal of Information Systems, Vol. 4, N. 1, p. 130-142. Witten, Bentley and Dittman, 2004, Systems Analysis and Design Methods, 6 ed., McGrawHill. Wynekoop, J. e Russo, N., 1997, Studying system development methodologies: an examination of research methods, Information Systems Journal, Vol. 7, n 1, pp. 47-65. Yourdon, E., 1992, Anlise Estruturada Moderna (traduo da 3 ed. americana [1989]), Editora Campus.
Pgina 114

O Essencial Da Análise de Sistemas

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

O Essencial Da Análise de Sistemas

Uploaded by

Copyright:

Available Formats

O Essencial da Anlise de Sistemas

Universidade Fernando Pessoa

lvaro Rocha (2008), O Essencial da Anlise de Sistemas. UFP

lvaro Rocha (2008), O Essencial da Anlise de Sistemas. UFP

desenvolvimento dos contedos apresentados neste livro.

lvaro Rocha (2008), O Essencial da Anlise de Sistemas. UFP

Desenvolvimento de Sistemas de Informao

Figura 2.1: Actividades tradicionais no desenvolvimento de SI.

lvaro Rocha (2008), O Essencial da Anlise de Sistemas. UFP

Figura 2.2: Alteraes s actividades tradicionais de desenvolvimento de SI.

lvaro Rocha (2008), O Essencial da Anlise de Sistemas. UFP

lvaro Rocha (2008), O Essencial da Anlise de Sistemas. UFP

Nveis de Interveno da Anlise de Sistemas

SO - Sistema Organizacional SI - Sistema de Informao SW - Software (Sistema Informtico)

Figura 3.1: Componentes e nveis principais da anlise de sistemas.

lvaro Rocha (2008), O Essencial da Anlise de Sistemas. UFP

Processo de Anlise de Sistemas

Declarao informal de requisitos

Documento e relatrio de validao dos requisitos

Obteno ou Definio INCIO Validao

Anlise e Negociao Requisitos acordados Documentao

Documento rascunho de requisitos

Importncia da Anlise de Sistemas

lvaro Rocha (2008), O Essencial da Anlise de Sistemas. UFP

lvaro Rocha (2008), O Essencial da Anlise de Sistemas. UFP

lvaro Rocha (2008), O Essencial da Anlise de Sistemas. UFP

ETHICS - Effective Technical and Human Implementation of Computer Based

lvaro Rocha (2008), O Essencial da Anlise de Sistemas. UFP

Representao e modelao dos diferentes Pontos de Vista

Anlise, Validao e Integrao

Soluo global reconciliada

Figura 3.3: Desenvolvimento e resoluo de pontos de vista.

lvaro Rocha (2008), O Essencial da Anlise de Sistemas. UFP

lvaro Rocha (2008), O Essencial da Anlise de Sistemas. UFP

Voluntarismo do comportamento organizacional e uso de SI

lvaro Rocha (2008), O Essencial da Anlise de Sistemas. UFP

lvaro Rocha (2008), O Essencial da Anlise de Sistemas. UFP

de Quo complexo o modelo

Quo diferente o modelo tcnico percebido ou pretendido?

o modelo tcnico imitado, adaptado ou original?

lvaro Rocha (2008), O Essencial da Anlise de Sistemas. UFP

- lista de clientes - informao geogrfica (mapas, grficos, etc.)

Figura 3.6: Nveis de descrio de processos/SI [adaptado de Nurcan et al. (1998)].

lvaro Rocha (2008), O Essencial da Anlise de Sistemas. UFP

Tabela 3.2: Exemplos de requisitos funcionais.

REQUISITOS FUNCIONAIS Orientados a processos

lvaro Rocha (2008), O Essencial da Anlise de Sistemas. UFP

Tabela 3.3: Exemplos de requisitos no-funcionais.

lvaro Rocha (2008), O Essencial da Anlise de Sistemas. UFP

lvaro Rocha (2008), O Essencial da Anlise de Sistemas. UFP

lvaro Rocha (2008), O Essencial da Anlise de Sistemas. UFP

lvaro Rocha (2008), O Essencial da Anlise de Sistemas. UFP

lvaro Rocha (2008), O Essencial da Anlise de Sistemas. UFP

4.2.1 Tcnicas de observao

Figura 4.1: Determinao de requisitos por observao do comportamento.

lvaro Rocha (2008), O Essencial da Anlise de Sistemas. UFP

Como faz isso?

Figura 4.2: Obteno e determinao de requisitos atravs de aprendizagem com o utilizador.

lvaro Rocha (2008), O Essencial da Anlise de Sistemas. UFP

lvaro Rocha (2008), O Essencial da Anlise de Sistemas. UFP

Formulrio de Avaliao de Prottipo

Figura 4.4: Exemplo de formulrio de avaliao de prottipo.

4.2.2 Tcnicas de levantamento no-estruturado