Guia de Estudos para Análise de Sistemas de Software - Prof. Itana Gimenes

Prévia do material em texto

Guia de Estudos para Análise de Sistemas de Software 
Itana Gimenes 
Universidade Estadual de Maringá 
Departamento de Informática 
2014 
1. Introdução 
Este guia resume pontos importantes nos estudos e elaboração dos trabalhos da disciplina 
Análise de Sistemas de Software (5181, 6891) dos cursos de Informática e Ciência da 
Computação da Universidade Estadual de Maringá. É importante o uso dos livros textos de 
(Arlow & Neustadt, 2009) e (Wazlawick, 2004), mas também pode ser consultado o livro dos 
criadores do processo unificado (Jacobson, Booch, & Rumbaugh, 1999). O artigo sobre casos 
de uso ( Jacobson, 2002) é relevante para entendimento e acompanhamento da disciplina. 
A disciplina segue o processo unificado conforme (Arlow & Neustadt, 2009). Porém, 
aproveitamos recursos comuns e adicionais introduzidos em (Wazlawick, 2004) que é o livro 
em português mais próximo da forma em que a disciplina é ministrada. 
Os modelos devem ser especificados em UML. Notem que construiremos modelos de acordo 
com o processo unificado e que esses modelos serão representados de acordo com a sintaxe 
dos diagramas correspondentes em UML. Um diagrama UML pode ser utilizado para 
representar vários modelos de acordo com o processo a ser seguido. Então, prestem bem 
atenção em quando devem usar os termos modelo e diagrama. Por exemplo, o diagrama de 
pacotes serve tanto para representar a visão de negócios quanto para representar a 
arquitetura do sistema. 
Utilizamos como ferramenta de apoio o Astah versão Community 
(http://astah.net/editions/community). É importante estruturar a paleta de pacotes do Astah 
conforme os workflows do processo unificado ordenados, portanto para cada projeto devem 
ser criadas os seguintes pacotes: 
A-Requisitos 
B-Análise 
C-Projeto 
Os modelos de cada workflow devem ser desenhados dentro desses pacotes. Para entrega dos 
trabalhos, os grupos devem elaborar a especificação evolutiva de cada workflow contendo as 
descrições e os modelos solicitados e gerar um documento em pdf. Devem ser entregues 
ambos os documentos em pdf e o respectivo projeto em Astah em um único arquivo zip. 
É importante lembrar de salvar uma cópia backup dos modelos em Astah antes de começar o 
próximo workflow, pois os modelos são evolutivos. Para cada workflow, os grupos devem 
entregar também a especificação do workflow anterior corrigido. Por favor coloquem o nome 
do líder do grupo no nome dos arquivos a serem entregues, ex: NomeSobrenome-wfwreq-
relatorio e NomeSobrenome-wfwreq-astah. 
Observem ao final deste documento uma sugestão de estruturação da especificação do 
sistema. 
2. Exemplo 
Utilizamos como exemplo um sistema de gerenciamento de compras de um pequeno 
mercado. 
3. O Workflow de Requisitos 
 O primeiro workflow do processo unificado é o de captura de requisitos. Neste, os principais 
artefatos a serem elaborados são: 
• a visão de negócios; 
• o modelo de objetos de negócio, também conhecido como modelo conceitual ou 
modelo de domínio; 
• o modelo de casos de uso; 
• a arquitetura inicial do sistema; 
• Interface inicial do sistema; 
• Glossário de termos. 
 
 
 
 
3.1. A visão de Negócios 
Ao iniciar a especificação de um sistema é importante conhecer a organização em que ele está 
inserido para delimitar o sistema de seu ambiente e, portanto, reconhecer quais as 
funcionalidades do sistema a ser desenvolvido e quais ele demandará ou oferecerá para 
outros. Dessa forma, ficará claro inclusive para efeitos de elaboração de contrato entre o 
cliente e os desenvolvedores, quais as funcionalidades que serão contratadas. 
Assim, esta seção do trabalho deve conter uma descrição geral do sistema a ser desenvolvido, 
que pode ser obtida do documento de requisitos. 
A Figura 1 mostra a visão de negócios do sistema de gerenciamento de mercado. Esta visão é 
representada pelo diagrama de pacotes UML que contém pacotes e setas representando as 
dependências entre os sistemas envolvidos. O sistema a ser desenvolvido é o de 
Gerenciamento de mercado que utilizará informações do sistema de Recursos humanos e 
do Fornecedor de produto. Note que as setas de dependências não representam fluxos de 
dados, elas mostram que os sistemas dependem um dos outros para o efetivo funcionamento 
dos mesmos. Organize os pacotes de forma hierárquica colocando o seu sistema no topo e 
abaixo os sistemas dos quais ele depende. 
Existe apenas uma forma de modelar um sistema? 
R: Não, os modelos representam a visão do desenvolvedor e podem variar. No 
entanto, pessoas que tem experiência no domínio têm facilidade de notar 
inconsistências nos modelos. 
 
Figura 2: Visão de negócios do sistema de gerenciamento de mercado. 
3.2. O Modelo de Objetos de Negócio 
O modelo de objetos de negócios é também referenciado na literatura como modelo 
conceitual ou modelo de domínio. Ele contém os principais conceitos inerentes ao sistema que 
podem ser facilmente visualizados sem se pensar numa solução de software específica. Este 
modelo é representado pelo diagrama de classes. Cada conceito é representado por uma 
classe. Neste momento, não é importante o aprofundamento das classes em termos de 
atributos e métodos, portanto a representação desses elementos foi omitida da Figura 2. Esses 
conceitos são potenciais candidatos a constituir o banco de dados da aplicação. 
 
Figura 2: Modelo de Objetos de Negócio 
3.3. O modelo de casos de uso 
O modelo de casos de uso representa as principais funcionalidades de um sistema. Pode ser 
utilizado inicialmente como um recurso de comunicação entre o desenvolvedor e o cliente. 
Também será utilizado como referência para o workflow de análise. 
Conforme descrito em Waslawick (2004), os requisitos devem ser organizados de forma a 
facilitar a visualização: (i) das principais funcionalidades do sistema; (ii) dos casos de uso de 
manutenção (conhecidos como CRUD – Create, Read, Update, Delete); (iii) e consulta. Assim, 
os casos de usos podem ser organizados em (Wazlawick, 2004): 
a) Casos de uso principais – representam os principais processos do sistema. De acordo 
com (B. I. Jacobson, 2002), um caso de uso deve oferecer um valor significativo para 
um ator. É necessário analisar Valor do resultado x Ator específico, assim um caso de 
uso deve apresentar um resultado significativo que o cliente esteja disposto a pagar. 
b) Casos de uso de manutenção – esses casos de uso estão relacionados aos conceitos 
do sistema, representados no modelo de objetos de negócio. Também são conhecidos 
como operações de cadastro que são: criar, inserir, alterar, remover. Assim, como dito 
em (Wazlawick, 2004) pag. 45: “Nem sempre essas operações de manutenção vão 
aparecer nos casos de uso, e nem é necessário que isso aconteça. Basta definir quais 
são os conceitos (informações) que devem sofrer manutenção e indicar a 
implementação das operações de cadastro”. 
c) Casos de uso de consultas – uma consulta é uma operação de acesso a um conjunto de 
informações armazenadas no sistema, por exemplo, em seu banco de dados. Os 
resultados de uma consulta são estruturados em relatórios, por exemplo, um Relatório 
das contas correntes com saldo negativo. As operações de consulta não alteram o 
estado do sistema. O número de relatórios que podem ser retirados de um sistema é 
grande, portanto não é interessante representar essas operações no modelo de casos 
de uso principal. 
Observe que todas as operações acima são casos de uso; o argumento principal para realizar 
esta organização é tornar o modelo de caso de uso principal mais simples e significativo. 
Existem sistemas em que os casos de uso de manutenção possuem regras de negócios 
significativas associadas e é importante explicitá-las. Elas serão regras de integridade 
importantes do ponto de vista do banco de dados da aplicação. A organização proposta nãoimpede esta especificação mesmo que essas operações não apareçam no modelo de casos de 
uso principal. 
Vamos tomar como exemplo um sistema de gerenciamento de compras de um pequeno 
mercado. O modelo de caso de uso está na Figura 3. Neste aparecem os casos de uso de maior 
valor-resultado do sistema que são: F1: Comprar produto; F2: Efetuar pagamento e F3: 
Gerenciar produtos. Os atores que interagem com o sistema são Cliente, Funcionário e 
Fornecedor. Lembrem que os casos de uso devem ser rotulados com verbos no infinitivo. 
Observe também que os atores são aqueles que realmente interagem com o sistema 
participando da operação. Por exemplo, em um mercado em que o cliente compra apenas 
através do Funcionário ele não deve ter uma associação com Comprar produto. 
 
Figura 3: Modelo de casos de uso de um sistema de gerenciamento de compras de um 
mercado. 
Para cada caso de uso do modelo de casos de uso principal deve ser feita uma descrição. A 
Tabela 1 mostra o formato em que as descrições de caso de uso devem ser feitas. Note que a 
pré e pós-condição deve ser uma assertiva sobre o estado do sistema antes e após realizado o 
caso de uso. 
Caso de Uso: Comprar produtos 
Identificador: F1 
Descrição: apoia a compra de produtos. 
Ator (es): Cliente e Funcionário 
Pré-condição: Cliente ou Funcionário estar cadastrado. 
Pós-condição: Compra realizada 
Curso Normal: 
1. Cliente acessa página de compras ou vai ao mercado. 
2. Cliente entra com login e senha. 
3. Cliente escolhe os produtos 
4. Cliente solicita a compra dos produtos 
5. Sistema informa que a solicitação foi bem sucedida 
Tratamento das Exceções: 
1. Cliente entra com login ou senha errado 
1.1. Sistema emite mensagem de erro, volta e pede novamente login e senha. 
1.2. Sistema emite mensagem de compra não é possível após esgotada o número de 
tentativas 
 
 
Os casos de uso de manutenção são organizados como mostrado na Tabela 1. Note que nesta 
tabela aparecem todos os conceitos que aparecem no modelo de objetos de negócio. Para 
cada um deles aparecem as operações de manutenção que serão realizadas no sistema e em 
qual caso de uso será feita esta operação como indicado na referência cruzada. Assim, observe 
que o cliente usa o sistema de mercado para Comprar produto que é o caso de uso principal 
(F1); para tal precisa ter o cadastro no mercado então o caso de uso de manutenção Inserir (I) 
é acionado conforme consta na tabela. 
Tabela 1: Conceitos e operações de manutenção 
Conceito I A E C Observação 
Refe-
rência 
Cruza
da 
Cliente X X X X 
Não é possível excluir Cliente com fatura 
pendente de pagamento. F1 
Compra X X X X 
 Só é possível excluir uma compra quando estiver 
concluída F1 
Produto X X X X 
Só é possível excluir produto enquanto houver 
itens no estoque; 
Não é possível alterar o código de um produto. F3 
Fornecedor X X X X 
 Só é possível excluir um fornecedor se não 
houver produtos associados a ele F3 
Fatura X X Fatura apenas se pode criar e consultar F1 
 
Na tabela de consultas conforme mostra a Tabela 2, são anotados os relatórios que o 
sistema deverá emitir. 
Tabela 2: Consultas 
Nome Referência 
Vendas mensais F1 
Clientes suspensos F1 
Fornecedores F3 
 
3.4. Arquitetura do sistema 
O processo unificado é dirigido por arquitetura, portanto a arquitetura do sistema deve ser 
elaborada de forma evolutiva em todos os workflows deste processo. A arquitetura representa 
a divisão estrutural do sistema em partes e suas interconexões. Neste workflow, a arquitetura 
é construída agrupando-se os casos de uso em pacotes e estabelecendo as suas dependências. 
A Figura 4 mostra a arquitetura inicial do sistema de gerenciamento de mercado. 
 
Figura 4: Arquitetura Inicial do Sistema de Gerenciamento de Mercado. 
3.5. Glossário 
Aqui devem ser registrados e descritos os termos importantes utilizados no sistema. Note que 
todos os conceitos do modelo de objetos de negócio devem fazer parte do glossário. 
 
 
 
 
 
 
 
 
 
4. Workflow de Análise 
O segundo workflow do processo unificado é o Workflow de Análise. Neste, o principal 
artefato a ser construído é o Modelo de Análise. O objetivo do Workflow de 
Análise é refinar a especificação do sistema em direção à solução de software a ser 
desenvolvida, por isso dizemos que o Modelo de Análise é especificado em uma 
linguagem que os desenvolvedores entendem; em contraste aos modelos do workflow de 
requisitos que foram especificados em uma linguagem que os clientes entendem. 
O Modelo de Análise é composto dos seguintes elementos: 
• Classes de análise - Visão de cada caso de uso representada por um diagrama 
classe de análise para cada caso de uso. 
• Casos de uso – Realization - Análise (diagrama de comunicação) 
• Descrição da arquitetura (Análise) - Pacotes de análise, pacotes de serviços e 
suas dependências. 
• Visão global – diagrama de classes consolidado incluindo todas as classes do 
sistema. 
O Modelo de Análise apresenta uma visão interna do sistema, pois ele é utilizado 
pelos desenvolvedores para entender como o sistema deve ser projetado e implementado. De 
acordo com o processo unificado, ele é estruturado em classes estereotipadas e pacotes de 
análise e de serviços. Deve-se também especificar como concretizar os casos de uso do sistema 
mostrando como os objetos das classes de análise interagem para atingir os objetivos do caso 
de uso. 
Checklist de artefatos do Workflow de requisitos 
 Visão do negócio (diagrama de pacotes) 
 Modelo de objetos de negócio (diagrama de classes 
sem atributos e operações) 
 Modelo de casos de uso (com descrição detalhada de 
cada caso de uso) 
 Glossário – significado dos termos importantes do 
domínio do sistema 
 Tabelas de conceitos e consultas 
 Arquitetura inicial do sistema (Diagrama de pacotes) 
 Protótipo da Interface 
 
 
4.1. Descobrir as classes de análise 
As classes de análise são obtidas inicialmente das classes representadas no modelo de 
objetos de negócio (ou modelo conceitual). Porém, como o modelo conceitual é mais próximo 
do domínio do problema, ele geralmente inclui as classes que armazenam dados, não há uma 
preocupação com o processamento e a troca de mensagens entre as classes para alcançar os 
objetivos dos casos de uso. Nos modelos de análise vamos buscar a identificação dessas 
classes e a representação das interações entre elas para concretizar os casos de uso. Porém, é 
recomendado não dar ênfase em detalhes de projeto e implementação, tais como acesso a 
banco de dados, uso de tecnologia ou detalhes de desempenho. 
Uma das formas de encontrar as classes de análise é utilizar os estereótipos de classes de 
análise do processo unificado. Esses estereótipos são: limite (boundary), controle (control) e 
entidade (entity) que são representadas e definidas conforme segue: 
Classe com 
estereótipo 
Descrição 
 
Classe que intermedia as interações do sistema com o 
ambiente. É importante observar que não é a 
representação de interface gráfica. A preocupação 
principal é com as informações que entram e saem do 
sistema 
 
Classe que possui o algoritmo de gerenciamento do caso 
de uso. É aquela que recebe informações da interface, 
executa procedimentos buscando informações nas 
entidades e salvando as informações persistentes nas 
entidades. 
 
Classe que armazena dados persistentes. Elas têm origem 
no modelo conceitual e formam a base de dados do 
sistema. 
 
Esses estereótipos de classes tem origem no padrão de projeto Modelo-Visão-Controlador 
(MVC). Este padrão indica principalmente a separação da interface gráfica das classes que 
representam os objetos de modo que modificações na interface gráfica não impliquem em 
alteração nos objetos que armazenam os dados. 
Asclasses limite representam, tipicamente, informações encontradas em: 
 
1. Interfaces gráficas: por exemplo, se temos um formulário de cliente representado 
graficamente para entrada de nome, RG e endereço. A classe limite possui esses 
atributos independentemente das cores e artifícios gráficos que ela possa expor. 
2. Classes que intermediam interações com outros sistemas: por exemplo, ao chamar 
um sistema de validação de cartão de crédito, o sistema deve enviar o número do 
cartão e dados do cliente. 
3. Classes que intermediam interações com dispositivos externos: por exemplo, um 
sistema que adquire informações de um sensor de temperatura, ou interações 
com um atuador para disparar comandos para a porta de um elevador. 
As classes controle incorporam o comportamento principal dos casos de uso, por 
isso são geralmente nomeadas como gerenciadores ou controladores. 
As classes entidades, geralmente: cruzam vários casos de uso; são manipuladas por 
classes de controle; oferecem e recebem informações das classes limite; representam 
elementos chaves gerenciados pelo sistema; e, são persistentes. 
A maneira mais simples de se pensar é que para cada caso de uso teremos uma interface, 
um controlador e várias entidades. Porém, conforme se chama a atenção em (Arlow & 
Neustadt, 2009), isso pode levar a modelos distorcidos. O desenvolvedor deve especificar os 
controladores conforme a demanda do domínio do problema, assim controladores complexos 
podem ser decompostos de modo que um caso de uso tenha mais que um controlador. Da 
mesma forma, podemos descobrir que alguns controladores podem envolver mais de um caso 
de uso. Sistemas que são intensivos em dados, como por exemplo, comércio eletrônico, 
possuem controladores mais simples, enquanto que sistemas intensivos em software possuem 
controladores mais complexos, como por exemplo sistemas de planejamento e controle de 
produção. 
Um exemplo de classes de análise envolvida no caso de uso Comprar produto é 
mostrado na Figura 5. 
 
Figura 5- Classes de análise do caso de uso Comprar Produto. 
 No caso de uso Comprar produto um cliente envia/recebe informações através da 
classe ComprarProduto-I, o controlador GerenciamentoCompra-G executa as ações 
do caso de uso recebendo e enviando informações para as entidades ou outros controladores. 
Por exemplo, nota-se que é necessário: validar o acesso do cliente, verificar a disponibilidade 
do produto, registrar a Compra e acionar o pagamento, portanto foi colocado o 
relacionamento com os gerenciadores de acesso, produtos e pagamento onde serão 
detalhados os respectivos processos. 
Por exemplo, as classes de análise envolvidas no caso de uso Gerenciar acesso são 
apresentadas na Figura 6. 
 
Figura 6 – Classes de análise do caso de uso Gerenciar acesso. 
4.2. Concretização dos casos de uso 
Para cada caso de uso também é necessário pensar como os objetos das classes envolvidas 
trocarão mensagens para atingir o objetivo principal do caso de uso, neste exemplo, permitir 
que um cliente compre produtos. Essa representação é feita pelo Diagrama de Comunicação, 
como mostra a Figura 7. 
 
Figura 7 – Caso de uso – realization - análise. 
 
 
 
 
 
 
 
 
 
4.3. Análise Arquitetural 
Nesta etapa, deve-se pensar em como estruturar a arquitetura do sistema tomando como 
base: a arquitetura inicial produzida no workflow de requisitos (ver figura 4); as classes de 
análise; e, a concretização dos casos de uso. A arquitetura é representada pelo diagrama de 
pacotes, porém deve-se classificar os pacotes em dois níveis: análise e serviço, como ilustrado 
na Figura 8. Seguindo a estrutura em camadas proposta no processo unificado, os pacotes de 
análise fazem parte da Camada de aplicação específica enquanto os pacotes de serviço estão 
na Camada de aplicação geral. Os pacotes de serviço são usados pelos pacotes de análise 
assim, existe uma dependência entre eles. 
 
Figura 8 – Camadas da arquitetura do Workflow de análise. 
Na análise arquitetural o desenvolvedor deve minimizar as dependências entre pacotes, 
pois este é um indício de sistemas complexos. A arquitetura deve ser projetado de forma top-
down, assim as dependência devem ser de cima para baixo ou no máximo no mesmo nível. 
Note que a dependência significa que o pacote A precisa do pacote C para executar suas ações. 
Os pacotes da arquitetura no nível de análise são facilmente reconhecidos pelos analistas de 
domínio, pois eles ainda não contém detalhes de tecnologia nem foram afetados por 
necessidades de implementação. Os pacotes de serviço representam serviços fornecidos aos 
pacotes das camadas de mais alto nível, em geral, podem ser utilizados por mais de um 
pacote. Eles podem ser projetados para estruturar procedimentos repetidos nos pacotes de 
nível superior, podem surgir de relacionamentos do tipo <<include>> nos casos de uso. 
Exemplos de pacotes de serviço são verificar ortografia ou controlar acesso. 
Observações (Arlow & Neustadt, 2009) 
• As classes têm, em geral, de três a 5 responsabilidades (operações). 
• Classes não são solitárias – elas colaboram entre si. 
• Fique atento para a existência de muitas classes pequenas ou para 
classes muito grandes – encontre o balanço certo. 
• “Functoids” – procedimentos normais disfarçados de classes. 
• Classes onipotentes – pretendem fazer tudo. 
• Evite árvores de herança muito profundas. 
Um pacote em nível de análise pode ser rastreado para um ou mais casos de uso no nível 
de requisitos, assim como um caso de uso no nível de requisitos pode ser decomposto em 
mais de um pacote em nível de análise. 
Um princípio básico de arquitetura de software deve ser observado que é: alta coesão e 
baixo acoplamento. Assim, deve-se manter o máximo de comunicação entre as classes dentro 
de um mesmo pacote, evitando acessar pacotes externos para obter baixo acoplamento. 
As figuras 9a e 9b ilustram situações que podem ocorrer na concretização dos casos de uso 
que podem levar a refatoramento na arquitetura. Na Figura 9a, a entidade E1 é utilizada em 
mais de um caso de uso, portanto foi refatorado no pacote C3. Porém, podem acontecer 
situações em que controladores ou funcionalidades estão repetidas então pode-se refatorar 
também os controladores como mostra a Figura 9b. 
 
Figura 9a – exemplo de refatoramento de arquitetura. 
 
Figura 9b - exemplo de refatoramento de arquitetura. 
 
 
 
 
 
 
 
 
5. Referências 
Arlow, J., & Neustadt, I. (2009). UML 2 and The Unified Process - Practical Object-Oriented 
Analysis and Design (p. 592). Upper Saddle River, USA. 
Jacobson, B. I. (2002). Use Cases — Yesterday , Today , and Tomorrow. 
Jacobson, I., Booch, G., & Rumbaugh, J. (199AD). The Unified Software Development Process (p. 
512). Addison-Wesley Professional. 
Wazlawick, R. (2004). Análise e Projeto de Sistemas de Informação (p. 298). Rio de Janeiro, 
Brasil. 
 
 
Checklist – artefatos a serem entregues como resultado do 
Workflow de Análise: 
 Classes de análise para cada caso de uso – um diagrama 
classes estereotipadas para cada caso de uso. 
 Casos de uso – Realization - Analysis (diagrama de 
comunicação) 
 Descrição da arquitetura (Análise) - Pacotes de análise, 
pacotes de serviços e suas dependências. 
 Visão global – digrama de classes consolidado incluindo todas 
 
 
Universidade Estadual de Maringá 
Departamento de Informática 
Curso: <Informática> | <Ciência da Computação> 
Disciplina: Análise de Sistemas de Software 
Ano: 2014 
 
 
 
Especificação do Sistema de <....> 
 
 
 
Grupo: 
<RA> Nome ... 
 
Sumário < construir o sumário com os itens de cada workflow> 
1. Introdução < introdução ao documento incluindo uma descrição geral do sistema a serespecificado> 
2. Workflow de Captura de Requisitos 
2.1. Visão do negócio 
2.2. Modelo de objetos de negócio 
2.3. Modelo de casos de uso 
2.4. Tabelas de conceitos e consultas 
2.5. Arquitetura inicial do sistema 
2.6. Protótipo da Interface 
2.7. Glossário 
3. Workflow de Análise 
3.1. ... 
4. Workflow de Projeto 
4.1. .... 
 
Revisões 
 
Versão Autores Descrição Data 
1.0 Fulano Workflow de Captura de Requisitos 99/99/99 
 
 
 
 
 
<note que o documento é progressivo, ao final do curso vocês terão a especificação completa> 
< a seguir incluir as seções do documento> 
 
	1. Introdução
	2. Exemplo
	3. O Workflow de Requisitos
	3.1. A visão de Negócios
	3.2. O Modelo de Objetos de Negócio
	3.3. O modelo de casos de uso
	3.4. Arquitetura do sistema
	3.5. Glossário
	4. Workflow de Análise
	4.1. Descobrir as classes de análise
	4.2. Concretização dos casos de uso
	4.3. Análise Arquitetural
	5. Referências