ANÁLISE E PROJETO DE SISTEMAS

REVISÃO DA DISCIPLINA

 Requisitos: Da criação do seu primeiro projeto ao desenvolvimento a criação de um grande software

corporativo os requisitos servem como base para definir o escopo da solução e negociar características
do projeto com os clientes.
 Importância da definição de escopo: O escopo correto garante que os documentos do projeto atendam
as expectativas dos clientes internos e externos.
 Identificar e documentar: Requisitos e Regras de negócio.
Um diagrama de casos de uso é uma representação visual simples da interação do usuário com um sistema
e demonstra o relacionamento entre o usuário e as diferentes funcionalidades de um sistema. Um ator é uma
pessoa, organização, ou usuário externo que executa um papel em uma ou mais interação com um sistema.
Existem vários tipos de relacionamento que aparecem no diagrama:
 Associação entre ator e casos de uso;
 Associação entre casos de uso;
 Uma generalização entre dois atores;
 Uma generalização entre dois casos de uso
o <<include>>
o <<extend>>

As Regras de negócio definem o modelo ao qual a empresa realiza suas atividades e entrega seus
produtos/serviços. As regras de negócio podem ser:
 Cálculos ou fórmulas matemáticas associadas ao negócio ou a legislação;
 Restrições que definem regras sobre o que não pode ser feitas em determinadas situações, procurando
normalmente evitar riscos operacionais;
 Habilitação de ação que define regras dedutivas, ou seja, regras que quando aplicadas em sequência
levam a uma descoberta;
 Termo, uma parte de uma regra que é usada em conjunto com outras;
 Fatos descrevem verdades que relacionadas umas às outras podem ser usadas em termos;
 Interface é todo artefato em que o usuário aciona algo para obter uma reação
 Interação é o ato do usuário interpretar elementos de interface, tomar uma decisão e agir
 Affordance é a capacidade de um elemento ser convencional e facilmente interpretado pelo usuário
independente da cultura;
 O decreto lei de 5296/2004 (refere-se a acessibilidade) estabelece que sistemas computacionais devem
eliminar as barreiras que afetam o uso por parte de portadores de necessidades especiais;
 A IHC ou interação homem-computador é responsável pela comunicação realizada entre o ser humano
e o computador. Ela se preocupa com:
o navegabilidade, ou seja, com facilidade do usuário em encontrar, acessar e saber onde ele está
dentro do sistema;
o amigabilidade, refere-se a capacidade do desenvolvedor reduzir a complexidade e a carga
cognitiva para uso;
o em decorrência da IHC existem novas profissões como:
 Analista com especialidade de projeto centrado no usuário
 Arquiteto de informação
 Web designer
 Especialista em usabilidade
 Testador/avaliador
 Ao prototipar interfaces é de extrema importância trabalhar diretamente em conjunto com usuários reais,
fazer com que os patrocinadores do projeto (stakeholders) usem diretamente a solução.
 Lembre-se da importância de entender e conhecer o domínio do problema e de prototipar apenas aquilo
que é viável construir dentro das restrições do projeto.
 Vimos que a revisão da interface deve e pode ocorrer durante todo o ciclo de vida do desenvolvimento de
produto, ou seja, a interface com usuário requer feedback e avaliação constante com a participação do
usuário durante todo o processo.
o Métodos de inspeção: identificam problemas de uso ao fazer uma previsão sobre o
comportamento do usuário;

www.catolicasc.org.br
 o Avaliações heurísticas: identificam problemas de uso através de questionários que respondem
a diversas perguntas sobre as interfaces criadas. A Heurística mais popular para interfaces é a
de Nielsen (Você pode acessar neste link);
o Percursos cognitivos: através de simulação verifica como o usuário progride ao usar uma
determinada interface pela primeira vez.
 Trabalhamos também com o Diagrama de atividades e percebemos que ele permite modelar o
funcionamento de parte de um software (descrever um caso de uso) ou demonstrar como será a
execução de um processo (uma série de ações realizadas por diversos casos de uso). Destaca-se no
diagrama de atividades sua capacidade de demonstrar:
o Ações uma etapa do processo que os usuários ou softwares executam;
o Condições;
o Papéis (representados por swimlanes);
o Paralelismo (atividades que ocorrem simultaneamente).
 Quando falamos de analisar um problema a abordagem mais popular atualmente é a Orientada a Objetos
com uso da UML, a qual envolve diversas etapas e diversos diagramas. No entanto, não devemos nos
esquecer que independente da abordagem uma das primeiras verificações que deve ser feita é a
verificação da veracidade do problema, ou seja, o problema realmente vale a pena ser resolvido a
solução do problema cura uma dor real do cliente?
 De forma geral devemos:
1. Identificar o problema
2. Analisar o problema
3. Identificar as classes
4. Documentar a solução
 Vimos que o Diagrama de Classes pertence a etapa de projetos e serve como uma ferramenta que
define o modelo Orientado a Objetos que o projetista espera que seja criado no código fonte pelo
programador. O modelo é considerado estático, pois ele está diretamente relacionado a itens da sintaxe
da linguagem de programação e do compilador. São conceitos presentes no Diagrama:
o Classe
o Atributo
o Método
o Visibilidade
o Herança
o Associação
o Composição
 Um diagrama de sequência é uma forma de representar interação dentro de um determinado escopo, ou
seja, representa o comportamento dinâmico de um software (aquele que ocorre em runtime/execução de
um código).
 Um diagrama de sequência lembra um algoritmo, pois ele descreve como, e em qual ordem, um grupo de
objetos trabalha em conjunto.
 Diagrama de estados da UML permite entender o ciclo de vida de um objeto ou família de objetos,
mostrando os eventos que ocorrem desde a criação do objeto até a sua morte. Também estudamos
como adequar a solução conforme arquitetura a ser definida.
 O projeto de software é uma das etapas durante a criação de um sistema. Nessa etapa são tomadas
decisões sobre a arquitetura do software e os requisitos são transformados na solução, para que isso
ocorra as decisões devem ser documentadas e descritas para que todos membros do projeto adotem os
mesmos padrões. Lembre-se que a arquitetura trata de escolhas arquiteturais que são difíceis de ser
mudadas depois de implementadas. Na etapa de projeto temos:
o Projeto estrutural: uma versão abstrata de alto nível que representa o sistema formado por
múltiplos componentes que interagem entre si;
o Projeto de alto nível: quebra o projeto estrutural em uma visão menos abstrata de subsistemas e
módulos
o Projeto detalhado: demonstra a estrutura lógica de cada módulo.
 Diagramas de componentes permitem entender a configuração de um software e os relacionamentos de
dependências que o compõem, como por exemplo, bibliotecas externas. O diagrama descreve ainda:
Os arquivos de código fonte desenvolvidos;
o Os arquivos executáveis necessários para execução;
o Bancos de dados físicos que armazenam;
o Sistema de tolerância a falha;

www.catolicasc.org.br
 Os diagrama de implantação por sua vez permitem ver como os diversos componentes serão distribuídos
em um ambiente e como irão se comunicar.
 A análise orientada a objetos permite que sistemas complexos sejam modelados e implementados dentro
do paradigma de Orientação a Objetos que abrange o Ciclo de vida de software passando pelas etapas
de concepção, projeto, criação, implementação e manutenção.

www.catolicasc.org.br