P ARTE 2 – L INGUAGEM DE M ODELAÇÃO UML 8

Na figura anterior, poderíamos representar alguns processos com um nível de detalhe superior, e para isso já dispomos de informação no enunciado. Por exemplo, no caso do processo registo da requisição (1.1), o respectivo detalhe poderia incluir, e por esta ordem, a detecção da necessidade, a consulta à lista de bens disponíveis, o preenchimento da requisição, e o envio para o director. Esta informação seria também adequadamente representada por um diagrama de fluxo de dados, de nível mais detalhado.

Outro tipo de diagrama muito utilizado na literatura é o diagrama entidade associação (entity relationship diagram), que apresenta a visão estática do sistema, identificando as entidades sobre as quais interessa guardar informação, bem como o respectivo relacionamento. Na Figura 3.6 apresentamos o que poderia ser um diagrama deste tipo para o caso do problema da gestão de compras.

Qualquer relação expressa num diagrama entidade associação pode ser sempre analisada na perspectiva de ambas as entidades intervenientes, e implica a sua caracterização segundo dois conceitos adicionais: a cardinalidade (número máximo de ocorrências de cada uma na relação) e modularidade (número mínimo de ocorrências de cada uma, o que nos permite identificar quais são obrigatórias ou opcionais). Por exemplo, na relação entre "requisições" e "encomendas" do exemplo anterior, a cardinalidade desta relação, representada pelos símbolos mais próximos de cada rectângulo, lê-se "uma requisição pode ser satisfeita por várias encomendas"; a modularidade pode ser lida "podemos ter uma requisição que não dá origem a nenhuma encomenda" (é o caso em que o director não aprova o pedido).

Figura 3.6: Diagrama entidade associação para o exemplo da gestão de compras.

Estes diagramas melhoraram o rigor da especificação, uma vez que foram definidas algumas regras às quais é necessário obedecer na sua elaboração. Adicionalmente, a representação gráfica dos conceitos facilitou a sua compreensão por todos os intervenientes no processo (utilizadores e informáticos). No entanto, continuam a apresentar algum grau de subjectividade, até porque normalmente prevêem a utilização de descrições em linguagem natural para complementar a modelação efectuada. Além disto, a utilização de alguns termos e símbolos já muito próximos da tecnologia dificultou por vezes a compreensão dos diagra- mas por parte de participantes não técnicos.

Os diagramas até agora apresentados incluem-se no grupo das notações semi-formais, uma vez que tinham um conjunto de regras associadas, e que deviam ser aplicadas na sua elaboração. No entanto, não era possível através destes diagramas garantir e demonstrar a respectiva correcção, face às funcionalidades identificadas. No sentido de resolver este tipo de problema, foram propostas notações formais, que se caracterizam por adoptar conceitos muito próximos da matemá- tica, com o rigor e formalismo correspondentes, sendo deste modo possível demonstrar a correcção da especificação, o que é relevante

PARTE 2 – LINGUAGEM DE MODELAÇÃO UML

8 3

num número restrito, mas importante, de domínios de aplicação como seja a medicina, indústria militar ou a aeronáutica. Algumas notações mais conhecidas são:

§ Redes de Petri: diagramas particularmente adequados para a representação de sistemas com problemas de concorrência e com restrições a nível de sincronização; utiliza conceitos como transições, funções de input e de output [Leveson87].

§ Linguagem Z: linguagem de especificação formal, com simbologia e conceitos matemáticos e lógica de primeira ordem (conjuntos, tipos de dados, constantes, definições de estado, estado inicial, operações) [Spivey88].

Sai fora do âmbito deste livro aprofundar a aplicação das técnicas referidas. Para o leitor mais interessado aconselhamos a leitura da bibliografia recomendada.

3.4.4 Principais Metodologias

Foi referido no Capítulo 2 que o número de metodologias propostas para o desenvolvimento de software atingiu um número demasiado ele- vado, o que torna virtualmente impossível a sua apresentação em qual- quer livro. Por isso, enumeramos de seguida algumas das metodologias estruturadas conhecidas que maior relevância e divulgação tiveram. Para além destas, existiram outros contributos importantes que não incluímos aqui por não apresentarem uma perspectiva integrada de todo o processo de desenvolvimento, mas apenas sugerirem notações ou técnicas de modelação. É o caso, por exemplo, das propostas de Tom DeMarco [DeMarco78] e de Meiler Page-Jones [Page-Jones80].

SSADM

A metodologia mais divulgada e que alcançou maior sucesso foi o SSADM (Structured Systems Analysis and Design Methodology), proposta em 1981 por Learmonth, e alvo de sucessivas revisões, a última das quais em meados da década de 90, com o aparecimento da versão 4+ [Weaver98]. Durante muito tempo (e ainda hoje) foi conside-

rada a metodologia de referência e ensinada em diversos cursos universitários. No Reino Unido, foi durante muito tempo obrigatória a sua utilização em todos os projectos relacionados com o desenvolvi- mento de sistemas de informação a nível governamental.

O SSADM propõe a modelação de um sistema segundo três perspec- tivas complementares: (1) a sua funcionalidade; (2) a sua estrutura; e (3) a sua evolução ao longo do tempo. A primeira é representada através de diagramas de fluxo de dados (DFD), a segunda é obtida através de diagramas de entidade associação (DEA) e a terceira pelos diagramas de ciclos de vida de entidades. Estas três visões são integradas; por exemplo, os DFD são comparados com os DEA, de forma a garantir que cada entidade referida num DEA é criada por algum processo especificado num DFD.

É uma metodologia concebida sobretudo para a análise e desenho do sistema, não contemplando as tarefas relacionadas com a implemen- tação, testes e instalação do mesmo. Integra diversas notações orienta- das quer para a modelação dos processos quer dos dados. A sequência de actividades envolve:

§ A realização de um estudo de viabilidade, de modo a avaliar até que ponto o sistema tem custos aceitáveis.

§ A análise de requisitos do negócio. § A especificação dos mesmos requisitos.

§ A especificação lógica do sistema, de modo a determinar a forma como os requisitos identificados são implementados.

§ O desenho físico do sistema.

Para o leitor mais interessado aconselhamos uma leitura da referência anteriormente indicada.

STRADIS

Stradis (Structured analysis, design and implementation of information

systems) foi uma metodologia desenvolvida por Gane e Sarson em

finais da década de 70 [Gane82], baseada na filosofia de decomposição funcional top-down, e suportada essencialmente pela utilização de diagramas de fluxos de dados.

PARTE 2 – LINGUAGEM DE MODELAÇÃO UML

8 5