Esse artigo faz parte da revista SQL Magazine edição 52. Clique aqui para ler todos os artigos desta edição

widow-orphan; mso-outline-level: body-text">Modelagem

Projetando a arquitetura de sua aplicação utilizando UML

Um exemplo prático

 

Um produto de software nasce a partir das necessidades do mercado, de uma empresa ou apenas um usuário. Neste contexto, temos que a engenharia de software é voltada para a especificação, desenvolvimento e manutenção de sistemas de software, e objetiva desempenhar estas atividades assegurando princípios de organização, produtividade e qualidade.

Para isso, dentre outras coisas, ela oferece mecanismos para planejar e gerenciar o processo de desenvolvimento de sistemas de informação. Este é composto por várias fases, por exemplo: Planejamento do Processo para o Projeto (Definição do Objetivo, Definição do Escopo, Elaboração do Plano do Processo), Planejamento do Projeto (Estabelecer Cronograma, Planejar Recursos Humanos, Planejar Custos, Planejar Verificação e Validação), Requisitos (Levantamento de Requisitos, Especificar Requisitos Funcionais, Elaborar Matriz de Rastreabilidade, Verificar Requisitos, etc), Análise e Projeto do Software (Elaborar Diagrama de Classes, Elaborar Diagrama de Seqüência, Consolidar documento de projeto), Testes de Software (Elaborar Plano de Teste) e Implementação. Todas as fases são fundamentais no processo.

A fase de levantamento e especificação dos requisitos é muito importante. Requisitos bem definidos podem ser considerados um pré-requisito para um software de qualidade. Já as atividades de projetos estão alinhadas a uma série de transformações conceituais elaboradas pelos arquitetos de software de forma que tenhamos no final da fase um conjunto de diagramas (solução computacional) refletindo o conjunto de requisitos definidos. Neste contexto, destacamos o uso da UML para apoiar o projeto de softwares orientados a objetos. Sendo uma linguagem de modelagem, a UML permite que diversas perspectivas de visualização dos futuros produtos sejam definidas em diagramas padronizados (Casos de Uso, Diagrama de Classes, de Seqüência, Colaboração entre outros). Alem disso, facilita a comunicação entre membros da equipe de desenvolvimento por ser de fácil entendimento.

Neste artigo veremos na prática como desempenhar as atividades de definição dos Requisitos Funcionais, Descrição de Casos de Uso e Elaboração de Diagrama de Classes para um módulo de um software para apoiar Serviços de Medicina Ocupacional.

Estudo de caso

Utilizaremos como estudo de caso um software para apoiar Serviços de Medicina Ocupacional. Este projeto tem por objetivo criar uma ferramenta através da qual será possível efetuar cadastro dos pacientes da medicina ocupacional e pacientes internados junto com resultados dos testes médicos. Isto possibilitará criar e arquivar um histórico de todos os atendimentos médicos efetuados nesta empresa. Segue uma breve descrição do escopo do projeto:

·         lançamento das especificações da consulta médica (incluindo data de comparecimento, tipo, riscos, etc.);

·         lançamento dos dados dos pacientes (cadastro dos dados pessoais);

·         registro das especificações físicas (corporais);

·         registro dos exames, dos resultados dos mesmos (incluindo data de solicitação, de efetivação, resultados, local de arquivamento );

·         impressão dos atestados (SOSs, relatórios médicos parciais e finais);

·         impressão das fichas dos registros (dados pessoais).

·         impressão dos resumos (resumo dos atendimentos por data, mês, período, empresa, nome do paciente, tipo de exame, resultado do exame, etc).

 

Neste artigo, contemplaremos apenas parte deste escopo como poderá ser visto na próxima seção.

Especificação de requisitos do software

A atividade de especificação de requisitos do software é uma atividade bastante desafiadora. É complexo identificar as reais necessidades do cliente e depois formalizar o conhecimento obtido na especificação de requisitos do software. Neste artigo, faremos a definição dos requisitos funcionais para um pequeno módulo do software e, a partir destes requisitos funcionais, definiremos o diagrama de casos de uso e suas correspondentes descrições.

A definição da lista de requisitos funcionais pode ser considerada uma das primeiras tentativas de entender o escopo da aplicação que será desenvolvida. Esta definição é feita através de reuniões de identificação dos requisitos envolvendo clientes e analistas de requisitos. Para o software de apoio a uma organização que presta serviços em medicina ocupacional, chegou-se aos requisitos funcionais definidos na Tabela 1 (lembre-se que isto reflete apenas a parte do problema que será analisada aqui, e não o cenário do sistema como um todo).

 

RF1:

O software deve permitir que o Auxiliar de Escritório efetue o cadastro (inclusão, exclusão, alteração) de fichas médicas.

RF2:

O software deve permitir que o Auxiliar de Escritório efetue o bloqueio de uma ficha médica de forma que não possa ser mais alterada, apenas consultada.

...
Quer ler esse conteúdo completo? Tenha acesso completo