ISTEC

Tpicos detalhados da matria leccionada na cadeira de Engenharia de Software

Ver 3.1 31JAN2010

OBSs. sobre este documento: 1. constitui um complemento bibliografia (no pretende constituir material exclusivo para a preparao da cadeira); 2. encontra-se ainda em desenvolvimento; prxima verso: 8 de Fevereiro;

Docente: Eng. Sousa Mendes

1. Introduo A expresso Engenharia de Software foi introduzido pela NATO num estudo em 1967, e lanado no ano seguinte, numa conferncia na Alemanha a NATO Software Engineering Conference. O objectivo principal deste termo era chamar a ateno para o facto de os projectos de desenvolvimento de aplicaes informticas terem fortes semelhanas com os de engenharia, especialmente no que se refere a fiablidade do produto final, a cumprimento de prazos e custos, e a aspectos de manuteno. Tipicamente, os custos de manuteno de um produto informtico andam por cerca de 65% de todos os custos no ciclo de vida desse produto, e esse aspecto deve-se geralmente a falhas ou insuficincias nas fases de especificao e de concepo. A Engenharia de Software apresenta um conjunto de mtodos e tcnicas que procuram melhorar a qualidade dessas duas fases. 2. Elementos sobre evoluo das Tcnicas de Programao A actividade de programao comeou nos anos 40. Era feita segundo a abordagem bottom-up, i.e., no existiam princpios bem estabelecidos para o desenvolvimento, pelo que cada programador utilizava a lgica individual. Utilizava-se o chamado estilo esparguete, com grande recurso instruo GoTo. As diferenas de estilos de programao eram enormes e a manuteno de programas tornava-se uma tarefa complicada, o que levava, por vezes, os programadores a esquivarem-se a manter programas que no tivessem sido feitos por eles... Vrios esforos comearam, ento, a ser levados a cabo para se criar uma doutrina sobre tcnicas de programao. Em 1968, Ascher Opler, da IBM, iniciou o projecto Systems Programming, para recolher, organizar e publicar as melhores prticas de programao. Na sua sequncia, foram publicados documentos de trs tipos: bsicos (para iniciados), especializados (para programadores) e da Cincia da Computao (para investigadores). Desses esforos acabaram por resultar trs filosofias: orientao para os programas, orientao para os dados, e orientao para os objectos, que conduziram ao estabelecimento de diversas regras e tcnicas de programao, ou seja, a tcnicas topdown de fazer programao. Interessa-nos nesta cadeira analisar a evoluo das formas de fazer especificao de processos, uma vez que um dos grandes problemas tem sido a dificuldade em os tcnicos de informtica corresponderem s reais necessidades dos negcios. 2.1. Orientao para os programas Abordagem que j vinha de trs, caracterizada por considerar a figura do Programa como centro do SI. A anlise conceptual duma aplicao parte da perspectiva do seu funcionamento, sendo os dados vistos como acessrios dessse mesmo funcionamento. Podemos dizer que conduziam aos sistemas do tipo Push, por serem impostos ao utilizador final, sem qualquer colaborao destes na concepo e no desenvolvimento dos sistemas, e por serem explorados em ambientes de claro predomnio dos tcnicos de informtica. Os trabalhos de Asher Opler permitiram melhorar a forma como essa abordagem era usada, conduzindo ao aparecimento de tcnicas de programao estruturada. Estas devem-se em grande parte aos trabalhos de Chris Gane e Trish Sarson (Structured

Systems Analysis: tools and techniques, 1977), e Tom de Macro (Structured Analysis and Systems Specification, 1978). Segundo a aproximao ao programa, a pogramao deve utilizar uma srie de figuras lgicas de programao, organizadas em 3 tipos bsicos de estruturas de controlo: Sequncia, Seleco e Repetio: Sequncia (da estrutura de controlo Sequncia), SE ou CASO (da estrutura de controlo Seleco), e FAZER ENQUANTO ou FAZER AT (da estrutura de controlo Repetio). Para a especificao dos processos, os gestores devem utilizar tcnicas de PseudoCdigo e/ou do Fluxograma: a primeira utilizando uma linguagem estruturada, em qualquer lngua, apenas descrevendo a lgica do programa, sem grandes detalhes tcnicos, e a segunda fazendo o mesmo numa linguagem grfica simblica. Foi apresentada uma pseudo-linguagem simples para a efectuao de exerccios de especificao. instrues: INCIO nome_de_programa INCIO nome_de_rotina FIM ACEITAR texto ou varivel VISUALIZAR texto ou varivel IMPRIMIR(nome_de_mapa, campo_1, campo_2, ..., campo_n) FAZER rotina LIMPAR_ECR COMENTRIO Figuras lgicas: SEQUNCIA, SE e FAZER ENQUANTO Figura Lgica SEQUNCIA Qualquer bloco de instrues Figura Lgica SE SE condio ENTO instrues_1 SENO instrues_2 FIM_SE Figura Lgica FAZER ENQUANTO FAZER ENQUANTO condio instrues FIM_FAZER operadores: , (para afectao de valores a variveis ou campos) <, >, =, NO <, NO >, NO = (para comparaes) + (para operao de adio)

* / // ** E, OU , V

(para operao de subtraco) (para operao de multiplicao) (para operao de diviso real) (para diviso inteira) (para operao de exponenciao) (para operaes lgicas em pseudo-cdigo) (para operaes lgicas em fluxograma)

E foi estabelecida uma hierarquia de operadores. Rotinas so conjuntos de instrues que se repetem ao longo dum programa, e que, apresentando uma certa coeso lgica, constituem um bloco que com facilidade se pode distratar do programa sob a forma dum bloco autnomo, e sendo substitudo por uma simples referncia. Exerccios 1. Solicitar um nmero inteiro e apresentar a sequncia de inteiros at ele 2. Solicitar os comprimentos dos 3 lados de um tringulo e classific-lo quanto aos lados 3. solicitar os 3 parmetros de uma equao do 2 grau e apresentar as suas razes Para a especificao de processos envolvendo dados armazenados nos computadores foi apresentado o conceito de estruturas de dados, como formas de organizao dos dados, e a linguagem de especificao foi estendida a elas. Estruturas de dados simples (Registo, FilaSequencial, Vector, Lista Ligada) Estruturas de dados complexas (Matriz, Fila de Espera, rvore). Nas definies das diferentes estruturas pronunciamo-nos sobre tipo dos dados, contiguidade, cardinalidade e forma de acesso. Fila Sequencial Conjunto de dados do mesmo tipo, contguos fisicamente, com cardinalidade indefinida, que podem ser acedidos apenas sequencialmente. Estrutura que se cria num suporte no enderevel (fita magntica). Vector Conjunto de dados do mesmo tipo, contguos fisicamente, com cardinalidade bem definida, que podem ser acedidos directamente. Estrutura que se cria na memria RAM do computador. Princpio de funcionamento: Leitura e Escrita so simples transferncia entre variveis. Instrues primitivas: Criao de novo vector: INIC(vector, dimenso) Leitura: Vector(ndice) varivel Escrita: Varivel (ou texto) Vector(ndice) Ref. a Matrizes (vectores de vectores).

Exerccio 1: Carregar as pluviosidades no ms de Janeiro, considerando que so carregadas por ordem aleatria. No final a) permitir a consulta da pluviosidade dados os dias b) apresentar as pluviosidades ordenadas por dia c) apresentar as pluviosidades ordenadas ascendentemente. Lista Ligada Conjunto de dados do mesmo tipo, contguos apenas logicamente, com cardinalidade indefinida, que pdem ser acedidos sequencialmente. Estrutura que se cria num suporte enderevel. Cada elementos de uma lista ligada tem duas partes: - contedo (dado) - endereo do elemento seguinte. Duas excepes: a cabea da lista s tem endereo do elemento seguinte, e a cauda da lista no tem endereo do elemento seguinte e tem como contedo uma marca de fim. Princpio de funcionamento: coloca-se um elemento como corrente, e depois esse elemento pode ser lido, escrito, ou outro elemento pode ser afectado como seguinte a ele. Instrues primitivas: [OBS.: [...] - significa que os elementos no seu interior s eventualmente so necessrios] INIC(lista) - criar uma nova lista, de nome lista, s com cabea e cauda [OBS.: assume-se que os SOs, no final de cada sesso, eliminam as listas vazias.] AC-SEG(lista) - acede ao prximo elemento de dados (que pode ser o primeiro). [OBS.: se a lista existir, pode dar-se-lhe este como primeiro comando; no possvel dar qualquer outro comando sem fazer previamente um AC-SEG. A seguir a este comando tem que se testar o fim da estrutura, atravs de um comando Fazer Enquanto, sob a forma Fazer Enquanto no EOF (EOF significa End of File).] LER(lista; varivel) ESCR(E: lista, [texto ou varivel]) AF-SEG(lista1[, lista2]) [Observaes: 1: se for dado apenas o argumento Lista1, acrescenta-se apenas um elemento vazio; o argumento lista2 representa uma lista que eventualmente se pretenda inserir no elemento corrente; 2: os comsndos LER, ESCR-SEG e AF-SEG no alteram o elemento corrente; 3: o comando AF-SEG mantem sempre a mesma cauda da lista] ELIM(lista) elimina o elemento corrente. [OBS.: este comando l o endereo do elemento seguinte ao que se vai eliminar e coloca-o no elemento que vai passar a ser o elemento corrente]

Observe-se que os elementos das estruturas de dados podem ser eles prprios estruturas de dados. Com muita frequncia so Registos, i.e., conjuntos de dados de tipos diferentes, contguos fisicamente. Para fazer referncia a um campo de um registo utiliza-se a notao Registo.Campo (Exemplo: VISUALIZAR EMPREGADO.NOME). Exerccios: 1. Alterar uma lista ligada designada LISTA, impondo nela 327 como seu 4 elemento. 2. Solicitar os nomes de duas listas ligadas e a posio em que se pretende inserir uma na outra e fazer tal insero. 3. Considere na memria do seu computador o vector de pluviosidades criado nos exerccios anteriores, constitua-o em lista ligada e grave esse ficheiro em disco. 4. Considerando os ficheiros de organizao sequencial STOCKS e MOVIMENTOS, implementados segundo listas ligadas, cujos registos apresentem os campos seguintes, actualizar os stocks com os movimentos. STOCKS: Cdigo de Artigo, Designao, Unidade de Movimentao, Quantidade MOVIMENTO: Cdigo de Artigo, Tipo de Movimento (E-Entradas; S-Sadas), Quantidade Movimentada. Ref a Listas Especiais: Listas de contedos exteriores, Listas bidireccionais, Anis. Ref. evoluo de linguagens de programao: 1, 2, 3 e 4 gerao. Ref especial s linguagens de 4 gerao (4GL), tpicas dos ambientes de BDs. 2.2. Orientao para os Dados Os dados passam a ser considerados o centro do SI. A anlise conceptual parte da anlise dos dados necessrios ao negcio para a necessidade dos respectivos tratamentos. Foram recordados os conceitos de BD e SGBD. Referncia aos trs tipos de BDs: em Rede, Hierrquicas e Relacionais. As BDs hierrquicas e em rede assentavam sobre estruturas de dados mais evoludas que os sistemas organizados em ficheiros. Compreenso do Modelo Hierrquico As BDs hierrquicas s permitem implementar relacionamentos de 1:1 e de 1:N. Cada entidade do lado 1 cabea de uma lista ligada cujos elementos contm as entidades do lado N respectivas, e os dados do respectivo relacionamento. importante estabelecer a melhor estratgia de acesso aos dados. Compreenso do Modelo Reticulado As BDs em Rede permitem implementar todos os tipos de relacionamento, 1:1, 1:N ou N:N. Cada entidade vai ser cabea de uma lista ligada. Os relacionamentos so implementados segundo Anis, listas ligadas especiais que tm cabea mas no tem cauda, e a que normalmente se chama Sets. Cada Set tem um Owner (cabea da lista, que cada uma das entidades presentes) e pode ter vrios Members (conjuntos de elementos ligados uns aos outros, que contm os dados dos relacionamentos). Cada

Member pertence simultaneamente a, pelo menos, duas listas, contendo os dados do relacionamento das entidades que so cabeas dessas listas. Tambm neste modelo importante estabelecer a melhor estratgia de acesso aos dados. Compreenso do Modelo Relacional Elementos sobre a Histria das BDs Em 1962, Charles Bachman, da General Electric criou a primeira BD Reticulada - o Integrated Data Store. O facto de se revelar muito pesado para os sistemas, criou condies para o sucesso da implementao hierrquica, muito mais simples e leve, mas com a limitao de apenas permitir tratar os relacionamentos de 1:N. No seio da CODASYL constituiu-se ento um comit para a defesa do modelo reticulado. Foi o Database Task Group (DBTG), cujas especificaes se transformaram num standard. Em 1970, Edgar F. Codd, colaborador da IBM nos Laboratrios de S. Jos da Califrnia, e estudante de matemticas em regime ps-laboral, apresentou a sua tese sobre o Modelo Relacional: utilizando a figura matemtica da relao seria possvel implementar BDs de relativamente fcil explorao, com grande equilbrio nas respostas, no necessitando de definio de estratgias de acesso aos dados. Da nasceram dois grandes projectos: construo do System R, da IBM, que viria dar origem ao SQL, e a criao dum SGBD relacional na Universidade de Berkley, que viria a dar origem ao Ingres, de grande sucesso principalmente em ambientes acadmicos e de investigao. Elementos de lgebra Relacional DEFINIO MATEMTICA DE RELAO Dados os Conjuntos A, B, C, ... N, A {a1, a2, ..., an}, B {b1, b2, ..., bp}, ... e N {n1, n2, ..., nq} define-se Produto Cartesiano entre esses conjuntos como sendo um novo conjunto cujos elementos so sequncias ordenadas: A X B X ... X N { (ai,bj, ck, ..., nl) : aiA, bjB,ckC, ..., nlN} portanto o conjunto de todas as sequncias ordenadas que fr possvel constituir com os elementos dos conjuntos-factores. Define-se Relao entre conjuntos como sendo qualquer sub-conjunto do produto cartesiano definido sobre esses conjuntos, ou seja, um conjunto de sequncias ordenadas. ABC {(ai,bj, ck, ..., nl) : aiA, bjB,ckC, ..., nlN} O nmero de sequncias ordenadas constitutivas da Relao a Cardinalidade da Relao, e o nmero de elementos de cada sequncia ordenada o Grau da Relao.

Podemos, pois dizer que uma relao binria tem grau 2, e, mais geralmente, que uma relao n-ria tem grau n. Uma relao pode ser definida em compreenso ou em extenso. Na primeira, geralmente designada por Esquema de Relao, faz-se referncia apenas aos conjuntos sobre os quais ela se encontra definida, a que vulgar chamar atributos da relao: Nome(atrib1, atrib2,...,atribj,...), na segunda faz-se a explicitao de todas as suas sequncias, sob a forma de uma tabela. vulgar a identificao das tabelas duma Base de Dados Relacional atravs da apresentao dos respectivos Esquemas de Relao. No caso da tabela CURSO teramos CURSO(cdigo,designao,durao)(1) . Ao nmero de linhas da tabela que representa uma relao chama-se cardinalidade da relao: #(CURSO) = 3. Ao nmero de colunas, chama-se Grau da relao: Gr(CURSO) = 3. Numa Relao define-se Chave Candidata como sendo o conjunto mnimo de atributos capaz de identificar inequivocamente cada uma das suas linhas. Escolhe-se uma das chaves candidatas como Chave Primria da Relao (ou simplesmente Chave da Relao). Em cada relao encontra-se geralmente definida uma chave primria, ficando ento garantido que no existem casos repetidos. Na relao CURSO h duas chaves candidatas, Cdigo e Designao, e natural que delas se tome o Cdigo como chave da relao. A chave pode representar-se sublinhando o(s) atributo(s), ou afectando-o(s) de um asterisco: CURSO(Cdigo, Designao, Durao) ou CURSO(Cdigo*, Designao, Durao) . Como a chave identifica inequivocamente cada linha da relao, cada ocorrncia da chave no pode repetir-se, e normal as linhas da relao apresentarem-se ordenadas por tal chave, ou seja, normal que a chave da relao seja tambm a sua chave de ordenao. , porm, importante no confundir uma com outra: pode sujeitar-se uma

Apenas com a inteno de facilitar a distino entre nomes de tabelas e nomes de atributos, vamos escrever os primeiros em maisculas e os segundos em minsculas.

relao a uma ordenao por qualquer dos seus atributos, ou por qualquer conjunto dos seus atributos, mas a chave da relao mantm-se sempre a mesma. Por outro lado, os elementos de cada conjunto-factor do Produto Cartesiano sobre o qual definida uma relao constituem um Domnio da Relao. Ou seja, podemos designar por Domnio de um Atributo o conjunto de valores possveis desse atributo. Por exemplo, o domnio do atributo Designao na relao CURSO o conjunto das designaes de todos os cursos da Universidade: Domdesignao{designaes dos cursos da Universidade} OPERAES SOBRE RELAES Podemos definir 2 tipos de operaes sobre relaes: - de alto nvel - de mistura As operaes de alto nvel com mais interesse para o nosso estudo so: - Projeco - Seleco - Juno e as de mistura, - Interseco - Reunio - Complementar. Operaes de Alto Nvel Projeco A operao de projeco aplicada a uma relao conduz a uma nova relao com a mesma cardinalidade e com um grau menor ou igual ao da relao inicial. relp PROJ(rel, atribi[, atribj, ...]) (entre parntesis rectos encontram-se representados os parmetros opcionais, ou seja os que no tendo que se encontrar sempre presentes, podem ser necessrios em determinadas situaes). Ou seja, a relao-projeco obtem-se custa de alguns atributos da relao inicial (embora se possa impr que apaream por uma ordem diferente).

Como exemplo, podemos aplicar uma projeco relao CURSO referida anteriormente, de modo a obtermos uma relao com apenas dois dos seus atributos: REL_1 PROJ(CURSO,cdigo,durao) de que resultar uma nova relao: REL_1(cdigo,durao). Se se pretender garantir a inexistncia de linhas repetidas na relao final, uma vez que dela pode no fazer parte a chave completa da relao inicial, deve acrescentarse o parmetro * , tomando ento a definio matemtica estoutro aspecto: relp PROJ(rel, atribi[, atribj, ...,*]), pelo que, a cardinalidade da relao-projeco, pode ser menor que a da relao-origem. Seleco A operao de seleco aplicada a uma relao conduz a uma nova relao com o mesmo grau e com cardinalidade menor ou igual da relao inicial: relS SEL(rel, condioi[, operador lgico, condiok, ...]) ou seja, a Relao_Seleco obtem-se custa da imposio de condies relao inicial e ligando tais condies, eventualmente, por operadores lgicos (E, OU, Complementar). Podemos aplicar relao REL_1 uma Seleco que permita obter os cursos cuja durao seja de 5 anos: REL_2 SEL(REL_1,durao=3) de que resultar REL_2(cdigo,durao), Juno A operao de Juno permite articular duas relaes em torno de domnios comuns, gerando uma terceira relao cujo grau igual soma dos graus das relaes iniciais menos o nmero de domnios comuns:

10

relJ JUN(rel1,rel2, atrib1i - operador relacional - atrib2j,[- operador lgicoatrib1k- operador relacional - atrib2l -....])(2), sendo atrib1m- um atributo da 1 relao, e atrib2n, uma atributo da segunda. primeira relao da expresso anterior, rel1, chamaremos Relao Condutora da Juno (RCJ). Note-se que cada par de atributos com o mesmo domnio representado na relao-juno por apenas um atributo, com o nome do da RCJ. A cada atributo da RCJ cujo domnio seja igual a um da outra relao chamamos atributo-charneira. Haver, ento, tantos atributos-charneira quantos os domnios comuns s duas relaes, e os seus nomes so sempre nomes da RCJ. Se existir apenas um domnio comum entre as duas relaes operandas e a operao utilizada for a igualdade, teremos uma equijuno. Neste caso a expresso de definio costuma apresentar-se simplificada: relJ JUN(rel1, rel2, atrib1i). Sendo esta a situao que mais frequentemente nos interessa, design-la-emos, simplesmente, por juno, mas no podemos esquecer que h situaes em que teremos que recorrer a outros tipos. condio necessria e suficiente para que seja possvel aplicar a operao de juno a duas relaes, que elas apresentem um domnio comum. Esta operao apresenta grande interesse nos processos de descodificao: processo em que se pretende transformar um cdigo, existente numa tabela, na respectiva designao, existente noutra tabela. Neste processo, o cdigo a descodificar ser o atributo charneira e a relao em que se pretende fazer a descodificao aparece como Relao Condutora da Juno. tabela em que se encontra a designao chamaremos Tabela de Descodificao. Operaes de Mistura Aplicam-se s a relaes compatveis. Duas relaes dizem-se compatveis se forem do mesmo grau e os atributos da mesma ordem tiverem os mesmos domnios. Reunio de duas relaes compatveis uma relao compatvel com as anteriores em que cada sequncia ordenada pertence a uma ou a outra ou a ambas as relaes operandas:

Recordar do 1 captulo, que as operaes relacionais, na nossa gramtica, so > , <, =, NO >, NO <, NO =, e as operaes lgicas so , V, e \.

11

relU rel1 rel2

Interseco de duas relaes compatveis uma relao compatvel com as anteriores em que cada tuplo pertence simultaneamente s duas relaes operandas: relI rel1 rel2 Finalmente, encontrando-se uma relao B contida numa relao A, define-se Relao Complementar de B com respeito a A, uma relao compatvel com as anteriores, em que cada sequncia ordenada pertence a A mas no a B: relCBA relA \ relB importante observar que as operaes de actualizao efectuadas sobre Relaes (insero, alterao ou eliminao de casos) podem ser conseguidas atravs das operaes de mistura: insero: reunio da relao de cardinalidade singular constituida pelo caso a inserir, com a relao em que se pretende fazer a insero; eliminao: complementar da relao singular contendo o caso a eliminar com respeito relao em que se pretende fazer a eliminao; alterao: eliminao seguida de insero. Exerccios: 1. Considere que os Esquemas de Relao seguintes fazem parte do modelo relacional para o sistema de gesto dum Clube Desportivo: SCIO(Cdigo, Nome, Morada, Localiodade) MODALIDADE(Cdigo, Designao) INSCRIO(Scio, Modalidade, Data) Recorrendo s operaes de lgebra Relacional, obtenha resposta para as questes seguintes: a) Quantos scios tem o clube? b) Quais os scios residentes em Lisboa? c) Em que modalidades est inscrito o scio 720? d) Quais os scios que praticam tnis?

12

e) Quantas modalidades desportivas disponibiliza o clube aos seus scios? f) Quais as localidades em que residem scios do clube? g) Quais os scios que no esto inscritos em qualquer modalidade desportiva? 2. Considere que os Esquemas de Relao seguintes fazem parte do modelo relacional para o sistema de gesto duma Universidade: ALUNO(Nmero, Nome, Data de Admisso, Curso) PROFESSOR(Cdigo, Nome, rea de Formao, Data de Contrato) CADEIRA(Cdigo, Nome, Regente, Curso, Ano) CURSO(Cdigo, Nome, Nmero de Anos) INSCRIO(Aluno, Cadeira, Ano Lectivo, Classificao) Recorrendo s operaes de lgebra Relacional, obtenha resposta para as questes seguintes: a) Quantos alunos, e quais, entraram na Universidade em 1989? b) Quais os Professores da Universidade e respectivas reas de Formao? c) Quais as reas de Formao dos Professores da Universidade? d) Obter uma relao das Cadeiras com os respectivos Regentes. e) Quais os Regentes da Universidade? f) Qual a composio do curso GESTO? g) Constituir Turmas para a Cadeira G3.5, com o seguinte critrio: TURMA A: alunos cujo nome comece por A a L, TURMA B: os restantes. h) Que nota obteve o aluno Jos Antunes Reis na cadeira de Matemtica-II? i) Elaborar um Relatrio com as notas finais em 1991, na cadeira G3.5. j) Inserir o aluno nmero 327, Antnio de Oliveira Reis, no curso de Secretariado. k) Proceder seguinte alterao na Base de Dados: a cadeira de Matemtica II do curso de Gesto deixa de ser dada no 2 ano, passando a ser dada no 3. l) Eliminar da Base de Dados os alunos admitidos na Universidade antes de 1983. m) Quais os professores que no so regentes? 2.3. Orientao para os Objectos

13

A partir dos trabalhos de Asher Opler, referidos no incio destes tpicos, 30 anos de investigao, passando por desenvolvimentos como as Estruturas de Dados, as BDs, a Engenharia de Software, Dados Complexos, ou Inteligncia Artificial, conduziram aos SIs Orientados por Objectos (abordagem OO). Cada objecto tem Dados e Mtodos, um Estado e um Comportamento, de forma idntica aos objectos da nossa vida real. Os Dados traduzem as suas caractersticas estticas, e os Mtodos traduzem as suas caractersticas dinmicas. O Estado de um objecto corresponde ao conjunto dos valores dos dados num certo momento. O Comportamento corresponde ao conjunto dos mtodos. Caractersticas o termo genrico para dados e mtodos. Os SIs passam a ser considerados como objectos em interaco. A interaco conseguida agravs de mensagens que os objectos trocam entre si, de forma idntica a seres inteligentes. Uma mensagem composta basicamente por trs partes: um emissor, um receptor e um comando, podendo este ter argumentos, que determinam a que elementos do objecto se aplica o comando: Emissor Receptor Comando(argumentos) Uma das propriedades importantes dos objectos a Abstrao, que conduz ao conceito de Classe: uma Classe representa um conjunto de objectos com caractersticas comuns. Uma Classe pode ser representada atravs de um rectngulo com trs partes: Nome, Atributos e Operaes ou Servios. Aos atributos de uma classe correspondero dados em cada objecto concreto em que essa classe se instancie, e s operaes correspondero mtodos. Em relao a cada atributo duma classe podemos definir caractersticas para os dados que deles advierem: Tipo de Dados - Ex.: Caracteres, Numrico, Inteiro ou Decimal, Data, Memo, etc Restries - impostas aos contedos dos dados; ex.: >5, < 31-12-2004, etc Valor Inicial valor com que fica cada dado na sequncia da instanciao. Outras propriedades dos objectos: Encapsulamento - propriedade segundo a qual as caractersticas dos objectos esto escondidas do mundo exterior, ou seja, no so alterveis pelos utilizadores. Os utilizadores apenas podem dialogar com os objectos atravs do respectivo interface pblico (o protocolo do objecto). No podero alterar os seus mtodos... Hereditariedade - Propriedade segundo a qual cada classe pode ser vista como uma generalizao ou uma especializao de outra(s). Exemplo: um automvel de desporto pode ser visto como uma especializao da classe Automvel, e como generalizao da classe Frmula1. Polimorfismo - propriedade segundo a qual cada objecto reage de sua maneira a um dado comando, i.e., um mesmo comando dar origem a diversas reaces consoante o objecto que o receba. Duas das grandes diferenas entre Classes e Entidades, estudadas na concepo das BDs relacionais, so: por um lado, as classes tm operaes e as entidades no, por outro,

14

enquanto que os atributos das entidades esto sujeitos a restries, de forma a darem origem a relaes normalizadas, um atributo de um objecto pode ser qualquer tipo de dados: grfico, estrutura com coordenadas espaciais, documentos, imagens, som, regras, e pode ser atmico ou no. Pode, por exemplo, ser uma estrutura de dados como um vector ou uma matriz. A grande limitao do modelo relacional reside no facto de ele no conseguir tratar directamente os relacionamentos N:N. Este problema fica resolvido no mundo dos objectos: a cada classe do diagrama de classes vai corresponder uma e um s ente no modelo lgico. O principal inconveniente tem a ver com um certo retrocesso na facilidade de interaco com os utilizadores finais: as linguagens de 4 gerao no so ainda utilizveis em ambiente OO, e no est ainda universalmente aceite ao que se poder vir a chamar linguagens de 5 gerao. No princpio dos anos 90 proliferaram as linguagens de representao e elaborao de diagramas sobre objectos, tornando importante a escolha de uma linguagem standard. A linguagem UML (Unified Modeling Language) aparece na sequncia dos trabalhos de muitas pessoas e organizaes a partir da iniciativa de, especialmente, trs investigadores: James Rumbaugh, Ivar Jacobson e Grady Booch, e veio a ser considerada um standard, pela ISO. Esta linguagem til para analisar uma grande quantidade de situaes segundo uma grande diversidade de perspectivas. Nas aulas vimos fizemos uma abordagem muito simples, restringindo a sua aplicao a situaes simples de concepo de SIs. Cada um dos diagramas foi analisado de forma muito superficial, pretendendo apenas transmitir aos alunos as possibilidades bsicas da linguagem e a certeza de que a sua utilizao profissional exigir um estudo muito mais aprofundado. Obs.: foi feita referncia aos trs nveis de desenvolvimento de uma aplicao, e respectiva dependncia em relao s TIs de explorao. Diagramas Bsicos de UML Diagramas de Estrutura (Diagrama de Classes) Diagramas de Comportamento (Diagrama de Casos de Utilizao, Diagrama de Actividades, Diagrama de Estados, Diagrama de Interaco, estes, por sua vez, de dois tipos possveis: Diagrama de Sequncia e Diagrama de Colaborao) Diagramas de Arquitectura (Diagramas de Componentes e de Instalao). Na elaborao de cada diagrama necessrio ter preocupaes de sintaxe (aspectos formais) e preocupapes de semntica (aspectos de sentido). Deve ter-se presente que qualquer diagramas tem que poder ler-se e fazer sentido... Princpios gerais para elaborao do Diagrama de Casos de Utilizao (DCU): - viso geral do sistema; - elabora-se um diagrama destes por cada aplicao; - apresenta as grandes funcionalidades do sistema na perspectiva do utilizador da aplicao a desenvolver (a futura aplicao deve ter no menu de entrada muito aproximadamente as funcionalidades representadas neste diagrama); - a sintaxe de cada caso de utilizao deve aproximadamente na forma predicado + complemento directo (ex.: Receber Encomenda, Emitir Boletins de Vencimento) - a caixa central representa o sistema informtico, devendo ter na sua parte superior o nome do sistema;

15

- os actores podem ser internos ao negcio (geralmente representados do lado direito), ou externos (como fornecedores ou clientes e so geralmente representados do lado esquerdo); - um caso de utilizao representa um conjunto de actividades que possam ser desenvolvidas numa sesso de trabalho do sistema informtico, envolvendo um ou mais actores; - os actores podem ser pessoas individuais ou colectivas, ou podem ser outros sistemas; - no foram consideradas situaes de extends ou uses. Princpios gerais para elaborao do Diagrama de Actividades (DA): - apresenta de forma razoavelmente detalhada as actividades de cada caso de utilizao; - o conjunto dos DAs representa o sistema a perspectiva funcional do sistema; - elabora-se um DA por cada caso de utilizao do DCU; - uma pista por cada actor interveniente e uma pista (ou partio) para o sistema; - deve haver a preocupao de reduzir ao mnimo as actividades dos actores, passandoas o mais possvel para o sistema (se se chegar concluso de que um actor, eventualmente considerado no DCU, no necessita de fazer nada, deve eliminar-se do DA e do DCU); - elementos do DCA: pistas, actividades, smbolos de deciso, actividades concorrentes; - cada actividade deve inscrita numa caixa rectangular, sob a sintaxe predicado + complemento directo (ex.: Elaborar Pedido, ou Calcular o IVA); - deve haver apenas uma marca de incio e uma marca de fim; - no final de cada DA deve ser feito o levantamento dos respectivos cenrios: circuitos possveis atendendo s sadas das diversas decises (ex.: cliente novo proposta aceite equipamento no disponvel) - o conjunto dos DAs dum SI representa a perspectiva funcional do sistema - do conjunto de DAs devem ser deduzidos elementos sobre classes, relacionamentos, atributos (tanto de classes como de relacionamentos), e estados, elementos estes que sero utilizados nos diagramas seguintes. Princpios gerais para elaborao do Diagrama de Classes (DCl): - representa o sistema na perspectiva orgnica, i.e., dos dados (nele deve ser possvel encontrar resposta para todas as necessidades de dados do futuro sistema); - elabora-se um nico DCl por cada BD; - bastante semelhante ao diagrama de Entidade-Relacionamento; - mais legvel se for constitudo por duas partes: primeira: um grafo, em que as classes, representadas apenas pela caixa com o nome, so os ns, e os relacionamentos os arcos; segunda: as diversas classes, com os seus atributos, isoladas umas das outras; - as classes representam a viso esttica dos dados, e os relacionamentos a viso dinmica; -cada classe deve ser relevante para o negcio, ter um nome, um atributo identificador e, eventualmente, diversos atributos qualificadores; -as classes podem ser de natureza singular (ou patrimonial) ou de natureza plural (ou consumvel) - cada atributo deve ser relevante, elementar (no resultar de clculo ou de deduo), atmico (um valor nico para cada ocorrncia) e varivel (valores diferentes de ocorrncia para ocorrncia); - no deve haver qualquer redundncia nos atributos do DCl, i.e., cada atributo s pode existir numa classe ou num relacionamento (pode haver vrios cdigos, vrios nomes,

16

vrias quantidades, etc, mas cada um pertence a uma determinada classe ou a um determinado relacionamento); - foram considerados os seguintes tipos de relacionamentos: associao, composio, agregao e generalizao; - as associaes devem ter obrigatoriamente nome (um verbo com a funo de predicado) e cardinalidade, e podem ter opcionalmente um sentido de leitura e papis desempenhados pelas classes no relacionamento; as agregaes no necessitam de sentido de leitura nem de papis; as composies no necessitam dos elementos de que as agregaes no necessitam nem de nome, nem de cardinalidade (a no ser que se conhea o valor especfico das ocorrncias do lado n); as generalizaes no necessitam de nome, nem de cardinalidade, nem de papis. Princpios gerais para Transposio para o Modelo Relacional (MR): - o MR corresponde ao nvel lgico do desenvolvimento de SIs quando se pretende uma implementao em BD relacional; - cada classe d origem a uma relao (com uma excepo: classes relacionadas por associao 1:1 obrigatria de ambos os lados); - os atributos dos relacionamentos, quer eles sejam prprios ou partilhados, devem ficar sempre que posvel numa das relaes provenientes das classes que relacionam, i.e., s devem dar origem a novas relaes se de outra forma infringirem as formas normais das relaes das classes. Princpios gerais para elaborao do Diagrama de Estados (DE): - representam a perspectiva dos estados por que passam as diversas ocorrncias das classes, i.e., representam o ciclo de vida mais completo das ocorrncias das diversas classes do DCl; - um grafo em que cada n representa um estado e em que cada arco representa uma mudana de estado; - um DE por cada classe, embora haja classes cujo DE no tem interesse, no necessitando, portanto, de ser elaborados; - no tem smbolos de deciso; - na ponta de cada seta de mudana de estado deve escrever-se a aco que provoca a mudana de estado [NB: atender diferena entre acers e actividades]; - de cada estado podem sair ou chegar diversas mudanas de estado; - normal que se definam circuitos fechados entre estados, mas tem que haver sempre pelo menos uma entrada e uma sada para/de cada circuito - uma s marca de inicio e uma s marca de fim. Princpios gerais para elaborao do Diagrama de Sequncia (DS): - representam as mensagens que os objectos (objectos concretos, no classes) trocam entre si para que o sistema funcione - corresponde viso detalhada, sob a forma de mensagens entre objectos, das actividades do sistema dos diversos DAs; - foram vistos apenas dois tipos: sncronos (a cada mensagem de um objecto para outro corresponde sempre uma resposta) e instanciados (um DS por cada cenrio de cada DA); - cada objecto tem uma linha de vida; - os actores so objectivados atravs de objectos de interface; - deduzem-se dos DSs as operaes das diversas classes: cada mensagem a que um objecto capaz de responder um dos seus mtodos.

17

Princpios gerais para Transposio para o Modelo Lgico de Orientao para os objectos (MLOO): - o MLOO corresponde ao nvel lgico do desenvolvimento de SIs quando se pretende uma implementao em BDOO; [OBS.: o Modelo Lgico OO , de facto, o Diagrama de Classes completado com os atributos dos relacionamentos e com as operaes] - os atributos dos relacionamentos so includos em cada uma das classes que relacionam (ou em ambas); - contra o que acontece no Modelo Relacional, no se eliminam as classes que estejam ligadas a outras por relacionamentos 1:1 obrigatrios de ambos os lados. Foi, finalmente, proposta uma ordem de elaborao dos diversos diagramas de UML, considerando os dois possveis objectivos: construo de uma BD relacional ou construo de uma BDOO. 1 Exerccio de aplicao: Uma empresa aluga diversos tipos de equipamento. Os clientes celebram um contrato com a empresa sempre que efectuam um aluguer. Esse contrato refere, nomeadamente, o seguro que cobre o equipamento contra qualquer acidente que o danifique. Na altura da devoluo o aluguer facturado em funo do tipo de equipamento e da durao do aluguer. Um eventual atraso na devoluo implica a aplicao de uma multa que depende do tipo de equipamento. 2 Exerccio de aplicao: Pretende-se conceber uma aplicao para gerir um parque de estacionamento funcionando de acordo com os seguintes tpicos: - ocupa 3 pisos subterrneos dum prdio de apartamentos; - cada apartamento tem direito a um lugar de estacionamento, mediante um carto de residente e o pagamento de uma mensalidade; - qualquer pessoa pode parquear no parque, ocupando os lugares no cativos, mediate o pagamento de um valor horrio igual para todos esses lugares; - o pagamento feito atravs de mquinas de pagamento colocados no parque, pagandose exactamente o tempo de parqueamento ( parte o tempo de retirar o carro); - sada do parque existe um leitor de cartes, ligado s barreiras basculantes, que serve tanto para residentes como para no residentes; - a partir de certo valor pago em parqueamentos durante cada ms, os clientes no residentes tm direito a um desconto nos restantes parqueamentos nesse ms; - os veculos so identificados por uma cmara colocada entrada do parque, onde tambm existir um semforo indicando a disponibilidade de lugares. NB.: grande parte do primeiro exerccio foi realizada na aula; ele serviu, nomeadamente, para ilustrar cada um dos diagramas de UML estudados, e para mostrar como a partir desses diagramas se elabora o Modelo Relacional, a partir do qual se pode construir uma BD relacional, e o Modelo Lgico OO, a partir do qual se pode construir uma BDOO.

18

3. Mtodos de Desenvolvimento de SIs No desenvolvimento de um Sistema de Informao, devemos considerar duas perspectivas complementares que se devem articular muito bem: a do negcio, representado pelos gestores e utilizadores das futuras aplicaes, e a das TIs, representado pelos tcnicos de informtica. [Foi feita referncia norma ISO/IEC 12207, Software Life Cycle processes] Consoante o conhecimento que os gestores/utilizadores tenham do que se pretende, da dificuldade tcnica do seu desenvolvimento e do risco que esse desenvolvimento represente para a organizao, podemos considerar cinco mtodos de desenvolvimento bem distintos: Construir e Consertar, Prototipagem, Cascata, Incremental e Espiral. Vamos comear por analisar o terceiro, de uma forma detalhada, o que nos permitir, de seguida, entender os restantes de forma mais resumida. 3.1. O Modelo da Cascata (ou do Ciclo de Vida) 1. Identificar uma necessidade (ref. Oportunidades e Ameaas) 2. Descrever o problema e relacion-lo com o Plano Estratgico para o SI 3. Anlise-Diagnstico do problema (perceber bem o problema e detalh-lo) 4. Identificar e analisar solues alternativas: desenvolvimento interno, desenvolvimento externo, aquisio de package, ...) 5. Estudos de viabilidade tcnica e financeira, e considerao dos principais riscos, para cada uma das alternativas anteriores 6. Elaborao de Proposta para a Gesto (Prognstico) 7. Deciso da gesto, e sua divulgao como comprometimento da gesto de topo 8. Avaliao ex-ante: levantamento da situao actual e identificao de expectativas de todas as pessoas que, de alguma forma, tenham a ver com o futuro sistema (stakeholders); poder envolver a identificao de Factores Crticos de Sucesso (FCS), a utilizao da tcnica de Economia da Informao) 9. Desenvolvimento tcnico e implementao da aplicao (caso se tenha optado por desenvolvimento interno) 9.1. Obter dados detalhados, sobre a forma actual de trabalhar, analisar novas necessidades e elaborar uma Especificao de Requisitos, i.e., uma descrio textual do que se pretende obter com a nova aplicao 9.2. Arquitectura de sistemas (aspectos de articulao e funcionalidade de sistemas) 9.3. Anlise conceptual da nova aplicao (escolha de ferramentas CASE, diagramas em UML) 9.4. Escolha de plataformas tecnolgicas, para o desenvolvimento e para a explorao (de acordo com o planeamento estratgico) 9.5. Desenvolver Modelo Lgico (Modelo Relacional ou Modelos de objectos, Fluxogramas de programas, incio da preparao do Repositrio de Metadados) 9.6. Dar formao a tcnicos de informtica (eventualmente) 9.7. Planificao detalhada dos desenvolvimentos tcnicos a desenvolver (agendamento + afectao de recursos + oramentao) [OBS.: distinguir os termos Planeamento e Planificao]

19

9.8. Cinco actividades em paralelo: preparao de jogos de teste, preparao de aces de formao aos utilizadores, consituio de documentao de apoio aos utilizadores, desenvolvimento tcnico da aplicao (programao), incio do carregamento do Repositrio de Metadados (RMD) 9.9. Cinco actividades em paralelo: formao de utilizadores, testes das aplicaes, correces de SW, afinaes na documentao, migrao dos dados 9.10. Incio da implementao: instalao da nova aplicao em ambiente de explorao; funcionamento do novo sistema em paralelo com o antigo (se possvel) 9.11. Integrao com outras aplicaes 9.12. Aceitao formal e lanamento em explorao 10. Avaliao ex-post: para verificar se foram atingidas as expectativas identificadas na avaliao ex-ante (utilizando especialmente a tcnica de Economia da Informao) e avaliao financeira do projecto (utilizando tcnicas mais quantificadas, como ROI, ou Custo/Benefcio). 11. Acompanhamento e Manuteno (eventualmente atravs de Contrato de Manuteno). 12. Auditoria interna (eventualmente), com a finalidade de verificar compliance with requirements. Podemos concluir que o desenvolvimento de um SI pode envolver diversos tipos de actividades: Planeamento, Gesto de Projectos, Desenvolvimento de Aplicaes, Preparao de Utilizadores (Gsto da Mudana), Apoio Explorao. Requer portanto um leque diversificado de conhecimentos e de experincias, muito para alm do que o ensino universitrio pode oferecer... 3.2. Casos Especiais Quanto complexidade, ao nvel de conhecimento da comunidade utilizadora e ao risco do desenvolvimento, as aplicaes podem classificar-se em: aplicaes muito simples e comunidade utilizadora razoavelmente evoluda, aplicaes simples em que os utilizadores sabem bem o que pretendem da aplicao, podendo elaborar uma especificao de requisitos, aplicaes simples em que os utilizadores no sabem bem descrever aquilo de que necessitam, aplicaes complexas e aplicaes muito complexas e/ou arriscadas. Os mtodos a utilizar no desenvolvimento devem ser funo desses aspectos: - Aplicao muito simples e comunidade utilizadora razoavelmente evoluda Mtodo Construir e Consertar (ver referncia a Trabalhadores do Conhecimento) - Aplicaes Simples em que os utilizadores no tm capacidade para desenvolver Especificaes - Mtodo da Prototipagem, caracterizado por um trabalho iterativo e interactivo com grande colaborao dos utilizadores no desenho de ecrs e mapas - Aplicaes de alguma complexidade, em que os utilizadores elaboram Especificaes Mtodo do Ciclo de Vida (ou da Cascata), apresentado atrs - Aplicaes Complexas - Mtodo Incremental, em que a aplicao dividida em mdulos com diferentes prioridades, a ser desenvolvidos separadamente: s se iniciam os passos 9.7 a 9.11 de um mdulo quando os mesmos passos se encontrarem completos para o mdulo de prioridade imediatamente superior. - Aplicaes Muito Complexas e Arriscadas - Mtodo da Espiral: semelhante ao mtodo incremental, mas em que no incio de cada mdulo se aplicam os trs seguintes passos: 1. Anlise de risco

20

2. Anlise de impactos nas pessoas - a ser feito por especialistas 3. Gesto da Mudana - preparao das pessoas para a mudana organizacional que o mdulo impor, a ser feito de acordo com princpios que constituem a uma disciplina importante dos cursos de gesto, geralmente designada por Mudana Organizacional.

3.3. Mtodos e tcnicas de concepo de SIs Os mtodos mais vulgares so: Diagrama Entidade-Relacionamento (ER), de Chen, para a identificao dos dados (no desenvolvimento de BDs relacionais), ou IDEF1x (mais geral) Diagrama de Fluxo de Dados (DFD), para identificao de processos, ou IDEF0 Diagramas em UML, para desenvolvimento de BDs orientadas, ou no, por objectos. No desenvolvimento tcnico da soluo, independentemente da abordagem seguida, devem fazer-se avaliaes que permitam - rever custos, de acordo com o oramento estabelecido - rever prazos, de acordo com o plano estabelecido - rever os desempenhos dos programas, individualmente ou em conjugao, de acordo com mtricas estabelecidas - analisar eventuais alteraes que se revelem necessrias bem como os respectivos impactos no desenvolvimento. Dever fazer parte de tais avaliaes a elaborao de Relatrios, e os seus elementos ou concluses devem ser divulgadas pelas pessoas ou conjuntos de pessoas a quem possam ser considerados teis, contribuindo assim, para a aprendizagem colectiva (o que se designa vulgarmente por Aprendizagem Organizacional).

21

4. Qualidade do software Devemos considerar duas perspectivas: como garantir qualidade e como avaliar a qualidade. 4.1. Garantia de qualidade na produo de software Organizaes normalizadoras mais importantes nesta matria: ISO (International Standards Organization), com sede em Genve, na Suia. SEI (Software Engineering Institute), da Universidade de Carnegie-Mellon, nos USA. Conceito de Qualidade segundo a ISO - conjunto de atributos que permitem satisfazer necessidades, explcitas ou implcitas (tais atributos so designados por Dimenses da Qualidade). Quatro nveis de Qualidade nas organizaes: na Gesto, na Concepo, na Produo e na Utilizao. Referncia histrica: a preocupao real com sistemas de qualidade aparece no final da 2 Guerra Mundial, na sequncia dos trabalhos de, especialmente, dois nomes: Edwards Deming - americano, nascido em 1900, convidado para dar aulas no Japo logo a seguir guerra, e que foi o grande mentor do chamado Milagre Industrial do Japo. S nos anos 80 o seu nome se tornou conhecido nos EUA. Joseph Juran - nascido na Romnia em 1904, que tambm se tornou conhecido atravs dos seus trabalhos sobre Qualidade no Japo. As organizaes mais preocupadas com as questes da Qualidade passaram a adoptar a Gesto da Qualidade como uma rea autnoma, de forma idntica s reas de Gesto da Produo ou dos Recursos Humanos. E essa rea sub-divide-se geralmente em duas subreas: Garantia da Qualidade (que se ocupa da manuteno do Sistema de Gesto da Qualidade), e Controlo da Qualidade (que tem a ver com processos de avaliao). Sistema de Gesto da Qualidade (SGQ) - conjunto de pessoas, processos, mtodos e documentos que permitem garantir qualidade numa organizao ou num processo. As normas da srie ISO 9000 ocupam-se explicitamente da gesto e controlo da Qualidade nas organizaes. Dois princpios so especialmente importantes para a nossa matria: o princpio das Geraes dos Sistemas da Qualidade, de Ishikawa, e o Princpio da Melhoria Contnua, de Schewhart. Segundo Ishikawa, os SGQ devero evoluir da seguinte forma: 1 Gerao baseados em inspeces seguidas de correco dos defeitos 2 Gerao geridos por processos, de forma a evitar a gerao de defeitos 3 Gerao concebidos para obstar gerao de defeitos O Princpio da Melhoria Contnua (ou PDCA) defende que, qualquer processo deve ser permanantemente aperfeioado atravs da aplicao cclica das seguintes 4 aces: 1 planificar, 2 - fazer, 3 - verificar a qualidade, 4 - actuar nos elementos imperfeitos ou incorrectos, para nova planificao ... finalmente importante referir o conceito de Processo: conjunto de actividades, geridas de forma a produzir outputs que acrescentem valor mensurvel ao conjunto dos inputs, atravs de knowhow e do consumo de recursos.

22

Norma ISO9001:2000 A norma ISO9001 refere-se qualidade das actividades de produo, e a noma a ISO9001:2000 a verso de 2000 dessa norma. O aparecimento da norma ISO9001:2000 corresponde passagem 2 gerao de Ishikawa. Podemos pois dizer que esta norma responde ao aforismo: melhor prevenir que remediar... Princpio fundamental: uma organizao que pretenda demonstrar a sua aptido para proporcionar um produto a um cliente deve estabelecer um SGQ, document-lo, implement-lo, mant-lo e melhor-lo continuamente. Esta melhoria contnua segue o Princpio da Melhoria Contnua, de Shewhart. A norma fomenta uma abordagem por processos nas diversas fases do SGQ como forma de entender melhor o cliente e os requisitos do produto acrescentar valor s actividades melhorar os sistemas de avaliao favorecer o esforo de melhoria contnua (NOTA: o termo Produto pode abranger um produto p.d., um projecto ou um servio, e pode referir-se tanto a entidades internas como externas organizao) Nota: a verso anterior destinava-se especialmente a certificao e contratos, ou seja, tinha objectivos principalmente comerciais A norma ISO9001:2000 tanto mais aplicvel quanto mais a qualidade do produto final depender da qualidade de processos e tcnicas envolvidos maior for a facilidade em descrever o produto maior for a facilidade em descrever o processo produtivo maior for a facilidade em identificar e gerir as dimenses de qualidade do produto maior for a facilidade de identificar componentes maior for a facilidade de adquirir e gerir matrias primas e subsidirias maior for o conhecimento do contexto de explorao E a norma tanto mais til quanto mais contribuir para reduzir a exposio ao risco (ER) do produto final: Probabilidade de falhas * Impacto dessas falhas A norma pode ser considerada aplicvel e til em diversos aspectos relacionados com a gesto dos SIs, especialmente nos servios de apoio aos utilizadores e na produo de documentao de apoio, mas menos til na produo do software, e muito menos til na produo de informao, em sentido estrito. Compatibility Maturity Model (CMM) O objectivo do SEI, com a elaborao e publicao deste modelo em 1986, foi contribuir para a melhoria da qualidade do software atravs da melhoria dos processos de gesto dos projectos de desenvolvimento de software.

23

O CMM fornece a infraestrutura de gesto necessria para a consecuo de processos de desenvolvimento de software mais maduros e disciplinados, dentro dos prazos e oramentos estabelecidos. Podemos concluir, portanto, que este modelo complementar da norma ISO 9001:2000. Esta norma tem vindo a permitir a obteno de enormes ganhos de produtividade e de qualidade. Considera 5 nveis de maturidade na gesto dos projectos: Nvel Inicial ou ad-hoc a gesto feita de forma espontnea, sem grandes preocupaes organizativas. Um bom lder de projecto com uma boa equipa de colaboradores pode conseguir atingir um produto de qualidade, mas essa qualidade depende exclusivamente do esforo individual das pessoas envolvidas. Geralmente no se sabe bem quando o projecto terminar e quanto ir custar. Nvel Repetitivo encontram-se implementadas prticas bsicas de gesto de projectos, como planificao e oramentao (PERTs, Gantts, etc.). Projectos anlogos podem ser desenvolvidos de forma semelhante e podem ser comparados. Respeita os princpios da 1 gerao dos SGQs: ainda no funciona por processos, as falhas so corrigidas medida que so detectadas, e a preocupao dominante a eficincia. Nvel Definido o processo de desenvolvimento encontra-se completamente definido e documentado, tanto sob o ponto de vista tcnico como de gesto. De projecto para projecto vai-se afinando o processo, melhorando a forma de trabalhar e adaptando a documentao. Este nvel pertence 2 gerao de SGQs: preocupao de eficincia junta-se a de eficcia, para o que podem recorrer a ferramentas de CASE (ver abaixo) e contam com um sistema de gesto da qualidade mas no com um sistema de controlo da qualidade. o nvel em que se encontra a maior parte das software houses. Nvel Gerido estabelecem-se objectivos produtividade e de qualidade para cada projecto, e encontra-se implementado um sistema de controlo da Qualidade estatstico, funcionando com base em mtricas diversas. Este nvel pertence ainda 2 gerao de SGQs. Nvel Optimizado nvel de gesto por processos com aperfeioamento contnuo, implementados por sistemas de feed-back convenientes que, de forma automtica, obstem gerao de defeitos. Processos de acordo com a 3 gerao de SGQs. Tipicamente, so necessrios vrios anos para passar de uns nveis para os outros. O Departamento de Defesa dos EUA impe a certificao no 3 nvel do CMM aos concorrentes aos seus projectos. 4.2. Avaliao da qualidade no desenvolvimento de software Os riscos da actividade de desenvolvimento de SW tm estado associados especialmente a desvios dos custos ou dos prazos, mas agora necessrio passar a atender tambm a outros riscos: - riscos associados instabilidade dos Domnios de Aplicao dessas aplicaes - riscos inerentes ao facto de o SW se estar a tornar cada vez mais um factor crtico para cumprir a misso das organizaes, o que conduz por vezes a grandes presses sobre as estruturas informticas, aumentando o perigo de faltas de qualidade. Os processos bsicos a seguir no desenvolvimento de software so: gesto de requisitos, gesto de defeitos, gesto de configuraes.

24

Requisito cada uma das caractersticas e funcionalidades de que deve ser dotado o sistema, e cujo conjunto constitui a respectiva especificao. Gesto de Requisitos o processo de identificao, documentao, organizao e controlo dos requisitos de um sistema ou de propostas de alteraes a eles, com vista definio do produto a desenvolver, e ao estabelecimento da comunicao com o cliente, durante a produo ou a alterao do produto. Defeito uma nomalia ou falha num produto desenvolvido. Pode ser um problema grave, que impea o funcionamento do produto, total ou parcialmente, ou apenas uma no-conformidade com os requisitos definidos. Gesto de Defeitos o processo de anotao, comunicao e reparao de defeitos. Configurao a identificao e descrio dos componentes de um produto e da respectiva interligao. Gesto da Configuraes o processo de avaliao e aprovao de pedidos de alterao a componentes de configuraes, e coordenao dos trabalhos respectivos, garantindo permanentemente a integridade dos produtos. Gerindo correctamente estes processos, com o apoio de um conjunto de mtricas conveniente, poderemos garantir qualidade actividade de programao. 4.3. Avaliao da Qualidade nos produtos software Trs perspectivas sobre Qualidade de SW: conformidade com os requisitos, nvel de servio, e capacidade para permitir experimentao e inovao. Para avaliar a qualidade de um produto de SW necessrio comear por identificar o Domnio de Aplicao desse produto. Quatro tipos de domnios de aplicao de produtos SW: os especificos, os no especficos mas estveis, os no especficos nem estveis, mas cuja dinmica de evoluo est de acordo com a forma como se estabelece o conhecimento dos consumidores e dos produtos de SW, os no especficos nem estveis, caracterizados por evoluo em ambiente de grande complexidade. Quanto mais especficos forem os domnios de aplicao dos produtos mais a respectiva avaliao se pode fazer com base na conformidade com os requisitos. Quanto mais os produtos de SW se afastarem da especificidade e da estabilidade mais a respectiva avaliao se tem que fazer com base em outras dimenses de qualidade, como o nvel de servio ou a facilidade com que neles se pode fazer experimentao ou inovao. Dois principais aspectos permitem influenciar o Domnio de Aplicao dos produtos SW: - a interaco Gestores dos Produtos - Consumidores dos Produtos (utilizadores), o que conduz a um conhecimento em ambos os sentidos e permite qua avaliao se faa especialmente com base em aspectos de conformidade e de nvel de servio, - a dinmica de evoluo das TIs bsicas, o que pode conduzir ao aparecimento de uma comunidade utilizadora heterognea, de expectativas e graus de sofisticao diversificados, levando a que a avaliao dos produtos de SW se possa fazer apenas com base na possibilidade que eles ofeream de fazer experimentao e/ou inovao. Estes aspectos podem ser menos graves se a plataforma tecnolgica em que se verifarem os desenvolvimentos tiver uma longevidade razovel, ou se o tempo de lanamento dos novos desenvolvimentos for razovel , ou ainda se se estabelecer um processo de migrao dos antigos sistemas para os novos.

25

Independentemente da ptica adoptada, importante dotar o interface com o utilizador final de caractersticas convenientes: Dilogo simples e natural; Utilizao dos termos dos utilizadores (linguagem profissional); Minimizao da memorizao de informao; Consistncia na utilizao de palavras e expresses; Informaes referentes ao que est a acontecer; Marcao de forma clara das sadas dos crs; Disponibilizao de comandos rpidos (shortcuts); Mensagens de erro claras; Minimizao da probabilidade de erros do utilizador pelo desenho do sistema; Disponibilidade de ajuda online e documentao.

26

5. Ferramentas CASE Segundo o SEI, ferrmentas CASE (Computer Aided Software Engineering) so o conjunto de meios e tcnicas de suporte, baseados em computador, utilizados no processo de concepo e desenvolvimento de Sw. Estas ferramentas podem permitir fazer o Forward Engineering ou o Reverse Engineering. Foi apresentada a representao grfica do processo de desenvolvimento, com referncia a termos como Linguagens interpretveis e compilveis, Compilao, Linkagem, Interpretao, Mdulos Absolutos, Mdulos Objectos, Bibliotecas, .... As ferramentas CASE apoiam as actividades de modelao, desenvolvimento de cdigo, compilao, produo de documentao, etc. O incio deste tipo de ferramentas remonta aos anos 70, quando o sistema operativo UNIX apareceu com um conjunto de ferramentas integradas de apoio ao desenvolvimento. Os primeiros produtos de gerao automtica de cdigo aparecem no incio dos anos 80. Evoluo histrica: 1. Ferramentas de apoio programao, como editores de texto, compiladores, interpretadores e ligadores (anos 60); 2. Ferramentas de elaborao de diagramas, para elaborar DFDs, Diagramas ER, Esquemas de BDs, gerao de documentao (anos 70; s em 1984 apareceu, porm, o primeiro produto expressamente com a funo de apoiar a anlise: o Excelerator; corria em PC com interface grfico e colocava a nfase na anlise, em detrimento da programao) 3. Ferramentas de RAD (Rapid Application Development), para gerao de cdigo, efectuao de testes, e gesto de projectos (anos 80) 4. Ambientes integrados de desenvolvimento, com a possibilidade de integrao de ferramentas, modelao orientada por objectos, capacidade de modelao do negcio (em 1992, a IBM publica o seu AD/Cycle, que veio a ter um sucesso reduzido). vulgar a distino entre ferramentas Lower CASE e Upper CASE: as primeiras especialmente teis nas fases de concepo, especificao e modelao, e as segundas, nas fases de desenvolvimento de cdigo, compilao e testes. Principais vantagens das ferramentas CASE: - uniformizao de tcnicas - capacidade de reutilizao - automatizao de processos de desenvolvimento - reduo do tempo de desenvolvimento - capacidade de integrao de mdulos de SW - aumento da qualidade dos projectos Principais limitaes: - elevado tempo de aprendizagem - custo dos produtos

27

- dificuldades na gerao automtica de cdigo - impossibilidade de converter processos de negcio em requisitos de informao. Duas suites interessantes de ferramentas CASE so o Paradigm Plus, da Computer Associates (CA), e o Rose, da Rational (posteriormente comprada pela IBM), de 2000, para ambiente Windows. O produto da CA resultou duma srie de aquisies que se desenrolaram por toda a dcada de 90. Foi apresentada nas aulas uma representao mostrando a articulao das suas ferramentas mais importantes: Modelao de SW, Modelao de BDs, Desenvolvimento de Aplicaes, Efectuao de Testes, Apoio a Configuraes, Modelao do Negcio e Gesto de Projectos, coordenadas pelo Sistema de Gesto de um Repositrio Central. Algumas suites de ferramentas CASE contam com a funcionalidade de Round-Trip Engineering, i.e., Forward Engineering e Reverse Engineering. Como ferramentas CASE menos abiciosas foram referidas nas aulas o VISIO e o Objecteering Modeler.

28

6. Elementos de Gesto de Projectos de desenvolvimento de software 6.1. Ferramentas de apoio a Planificao e Oramentao Planificar um projecto corresponde a identificar as principais fases e trabalhos do projecto, determinar quais desses trabalhos podem ser desenvolvidos em paralelo ou tm que ser desenvolvidos sequencialmente, e quais os recursos necessrios em cada fase. Veremos especialmente trs tipos de feramentas de planificao de projectos: PERT, Gantt, e CPM PERT PERT significa Program Evaluation and Review Technique. Foi uma tcnica desenvolvida em 1958 pela Marinha dos EUA, para apoiar os trabalhos de engenharia do projecto POLARIS, que conduziu primeira viagem espacial. As redes PERT so compostas por sequncias de Acontecimentos e Actividades. Um acontecimento definido como o ponto de incio ou de fim de uma actividade ou de um conjunto de actividades. Uma actividade o conjunto de trabalhos necessrios para passar de um acontecimento a outro. A tcnica PERT pode ser usada sob duas notaes: AOA activity on the arrow (actividades representadas por setas) AON activity on the node (actividades representadas por nodos) A notao AOA a mais usada manualmente, e a AON a mais usada com meios informticos. Exerccio: Construir o PERT correspondente a uma dada Estrutura de Decomposio de Trabalho (EDT, ou Work Breakdown Structure - WBS). Desenvolver o respectivo Gantt de actividades. Principais vantagens da notao AOA: - pe em relevo as inter-dependncias das diversas actividades - permite ver onde se deve colocar maior esforo para cumprir prazos - permite avaliar o impacto de alteraes nos recursos ou nos tempos Principais desvantagens da notao AOA: - torna-se complexo para projectos relativamente simples - recorre ao conceito de actividades fictcias - considera recursos ilimitados - reduz a liberdade da gesto Na notao AON, tambm chamada Mtodo do Diagrama de Precedncias, as actividades dum PERT so representadas por rectngulos que constituem os nodos da rede:

29

em que DIMC Data de Incio mais cedo DFMC Data de Fim mais cedo DIMT Data de Incio mais tarde DFMT Data de Incio mais tarde Id Identificao da actividade DEsp Durao Esperada A representao AON torna a rede mais simples de interpretar e elimina a necessidade de recurso a actividades fictcias. Exerccio: dado um PERT em notao AOA, convert-lo em notao AON [Obs.: atenda diferente notao dos momentos de incio e fim das actividades]. Obervar as seguintes relaes: DFMC = (DIMC + DEsp) 1 DIMT = DFMT - Desp + 1 DxMT = DxMC + Folga DIMCi = DFMCi -1 + 1 DFMTi = DIMTi+1 1 Nota: nesta notao representam-se os acontecimentos, ou Milestones, como actividades de durao zero, e nelas no se deve marcar DxMx, bastando identific-las com Mix, sendo x=1,2,3,.... CPM Aproximadamente ao mesmo tempo que a Marinha dos EUA desenvolvia a tcnica PERT, a empresa Dupont Company desenvolvia uma outra tcnica semelhante, a CPM, cuja sigla significa Critical Path Method. uma tcnica que procura determinar em cada momento o caminho crtico do projecto, ou seja, o conjunto de actividades em que qualquer atraso poder comprometer a data de concluso do projecto. uma tcnica que utiliza o PERT segundo a notao AON. [NOTA: de facto, o que normalmente se usa hoje como tcnica PERT o resultado de ambas] Durao Estimada e Durao Esperada A notao AOA da tcnica PERT especialmente indicada para projectos envolvendo actividades de natureza intelectual. Nestes, dado o grande nmero de factores de que dependem, a durao esperada de cada actividade apresenta grande variabilidade: se tudo correr bem, pode ter uma certa durao, mas se algo se complicar, pode ter uma durao completamente diferente. A experincia mostra, porm, que existe para cada actividade uma durao mais provvel. Estas duraes, optimista (O), pessimista (P) e mais provvel (M), designam-se por duraes estimadas (DEst). E a DEsp resulta de uma mdia pesada das DEsts: DEsp= (O+4M+P) / 6

30

A tcnica CPM mais utilizada para trabalhos do tipo construo ou montagem, em que as duraes estimadas se apresentam com menor variabilidade, pelo que se pode trabalhar com elas directamente. Este facto permite que, em cada momento, seja possvel determinar a percentagem de trabalho realizado. Gantt Gantt uma tcnica baseada num grfico de barras num sistema de eixos em que o eixo dos xx uma escala temporal. Deve o seu nome ao seu criador, H.L. Gantt, um enenheiro industrial, durante a I Guerra Mundial. As actividades de uma rede PERT podem ser representadas em funo do tempo atravs de um Gantt. Considerao de Recursos Como dissmos atrs, a tcnica PERT/CPM considera que os recursos so ilimitados. Para impormos uma limitao de recursos a um projecto temos que complementar a tcnica PERT com a Gantt. Se tivermos o mesmo recurso em vrias actividades dum projecto, e esse recurso tiver quantidade insuficiente para as necessidades totais, podemos, com o apoio da tcnica de Gantt, tentar viabilizar esse projecto deslocando actividades dentro das suas folgas. a isto que se chama Alisamento de Cargas. Devemos seguir, para isso, os seguintes passos: 1. Elaborao de PERT 2. Gantt de actividades 3. Gantt de cargas para recurso 1 4. Alisamento de cargas para o recurso 1(3) 5. Passos 3 e 4 para os restantes recursos do projecto 6. Adaptao do PERT Exerccios com recursos limitados 1. Viabilizar o projecto traduzido pela WBS seguinte, sabendo que todas as actividades utilizam o mesmo recurso, e que a capacidade desse recurso 14. Actividade A B C D Precedentes A B Durao 6 4 12 8 Unidades de Recurso 4 10 2 12

2. Viabilizar o projecto a que se refere a EDT seguinte, sabendo que a organizao que o leva a cabo dispe de apenas uma unidade de cada um dos recursos referidos. Actividades A B C D
3

Precedncias --------A A C

Durao 2 3 2 4

Recursos Rec1, Rec2 Rec1 Rec1, Rec2

esta tcnica pode tornar-se muito complexa se tivermos diversos recursos limitados no mesmo projecto

31

E F

D B, E

3 5

3. Viabilizar o projecto a que se refere a EDT seguinte, sabendo que a organizao que a leva a cabo dispe de 1 unidade do rec1 e 2 do rec2: Activ A B C D E Precedentes A B A Dur.Esperada 5 3 2 4 4 Qt Rec1 2 0 3 1 0 Qt Rec2 1 1 1 1 1

Oramentao Pode elaborar-se um oramento atravs de um Gantt para o recurso Dinheiro, e definindo, no eixo dos tempos, pontos de acumulao referentes aos perodos a que disserem respeito. 6.2. Durao de projectos envolvendo actividades de natureza intelectual A durao esperada de um projecto que no envolva actividades de natureza intelectual dada, muito aproximadamente pelo PERT que o representar. Se um projecto, porm, envolver actividades de natureza intelectual, como cada uma das fases ter uma durao esperada que resulta de uma mdia, a sua durao apenas ter uma probabilidade de 50% de ser igual durao esperada apresentada pelo respectivo PERT. E essa probabilidade estar de acordo com distribuio normal, ou seja, com a curva de Gauss. Um projecto de desenvolvimento de software envolve actividades de natureza intelectual, pelo que deve ser planificado atravs da tcnica PERT, com base em duraes esperadas resultantes de mdias pesadas de duraes estimadas. Um lder de um projecto, ao elaborar uma proposta de resposta a um Caderno de Encargos referente a um projecto de desenvolvimento de software, deve estar consciente de que a durao estabelecida por um eventual PERT que elabore para o projecto tem apenas uma probabilidade de 50% de ser cumprida. Com o auxlio da curva de Gauss e de frmulas convenientes, poder determinar uma durao que corresponda a uma probabilidade maior... Um eventual aumento da durao esperada de um projecto para aumentar a probabilidade de a cumprir designa-se por Reserva de Gesto. Para recorrer curva de Gauss, de acordo com a tabela distribuda nas aulas, utiliza-se a varivel z: z = (X-DurEsp)/, sendo X a durao a propr, DurEsp a durao esperada para o projecto, determinada atravs dum PERT, e o desvio padro do projecto. A varincia de um projecto dada pelo somatrio das varincias das actividades crticas (actividades do caminho crtico). E o desvio padro de uma actividade dado por

32

 i = (Pi-Oi)/6, em que Pi a durao pessimista estimada para a actividade i, e Oi a durao optimista estimada para a actividade i. Exerccio: a) Calcular a probabilidade de a durao do projecto traduzido pela EDT seguinte ser at 35 semanas (efectue os seus clculos com um erro inferior a 0,01). Actividade A B C D E F G H Precedentes A A B C D E F,G Dur.Estimada Optimista 4 6 5 3 7 2 6 2 Dur.Estimada Pessimista 13 11 9 7 10 5 8 4 Dur.Estimada Mais Provvel 7 9 7 5 8 3 7 3

b) Que durao se deve estabelecer para o projecto de forma que a probabilidade de a cumprir seja de 85% (efectue os seus clculos com um erro inferior a 0,01).

33