Aula5_2NA (1)

Prévia do material em texto

Análise de 
Desenvolvimento 
de Sistemas
Curso: Análise de Desenvolvimento de Sistemas
Professora: Dsc. Amanda Dantas
Análise e Modelagem de Sistemas
Resumo da Aula Anterior
Sistema da Informação
Resumo da Aula Anterior
Objetivo Principal: Auxiliar os 
processos de tomada de decisões nas 
organizações.
Sistema de Informação (SI)
Tipos de Sistema de Informação (SI):
Tipo Descrição
1.Sistemas de Processamento de Transações SPT
2.Sistemas de Informações Gerenciais SIG
3.Sistemas de Suporte à Decisão SSD
4.Sistemas de Suporte à Decisão em Grupo SSDG
5.Sistemas de Informação ao Executivo EIS
6.Sistemas de Automação de Escritório SAE
Resumo da Aula Anterior
Ciclo de vida de um 
software
Ciclo de Vida do Software
O ciclo de vida natural de um software abrange 
basicamente as fases:
1. Concepção (nascimento do sistema ou software)
2. Construção (análise e programação)
3. Implantação (pequenos ajustes pós-implantação)
4. Maturidade e Utilização Plena ( software 
sedimentado)
Ciclo de Vida do Software
O ciclo de vida natural de um software abrange 
basicamente as fases:
5. Declínio (dificuldade de continuidade)
6. Manutenção (tentativa de sobrevivência)
7. Morte (descontinuidade do sistema ou software)
Ciclo de Manutenção do Software
1. Manutenção Corretiva
2. Manutenção Adaptativa
3. Manutenção perfectiva
4. Manutenção preventiva ou preditiva
Resumo da Aula Anterior
Engenharia de Requisitos
Mundo Real
(Problema) Requisitos Software
(Solução)
Engenharia de Requisitos
Especificação de requisitos:
● É um contrato entre clientes e a 
equipe de desenvolvimento.
Engenharia de Requisitos
Especificação de requisitos:
● Deve esclarecer aos clientes o 
que será entregue como produto 
do trabalho da equipe de 
desenvolvimento.
 
Engenharia de Requisitos
Documentos da Especificação de requisitos
 
Visão Geral
Lista de 
Requisitos 
Funcionais
Lista de 
Requisitos Não 
funcionais 
Modelo do 
sistemaGlossário
Especificação 
detalhada de 
requisitos
Engenharia de Requisitos
Os níveis de detalhe podem ser subdivididos 
conforme três objetivos diferentes:
1. Delimitar o escopo preliminar e definir o escopo 
final da solução
2. Descrever o funcionamento e as restrições de um 
item no escopo
3. Mapear os requisitos para design ou 
implementação
 
Engenharia de Requisitos
Análise e Modelagem de Sistemas
Conteúdos da Aula de Hoje 
Modelagem de Sistemas
A partir dos modelos é possível compreender 
melhor o sistema que está sendo elaborado e 
gerenciar os riscos.
Fonte:Energy conservation in distributed 
heterogeneous computing environments 
using economic resource allocation 
mechanisms
https://www.researchgate.net/publication/259977469_Energy_conservation_in_distributed_heterogeneous_computing_environments_using_economic_resource_allocation_mechanisms?_tp=eyJjb250ZXh0Ijp7ImZpcnN0UGFnZSI6Il9kaXJlY3QiLCJwYWdlIjoiX2RpcmVjdCJ9fQ
https://www.researchgate.net/publication/259977469_Energy_conservation_in_distributed_heterogeneous_computing_environments_using_economic_resource_allocation_mechanisms?_tp=eyJjb250ZXh0Ijp7ImZpcnN0UGFnZSI6Il9kaXJlY3QiLCJwYWdlIjoiX2RpcmVjdCJ9fQ
https://www.researchgate.net/publication/259977469_Energy_conservation_in_distributed_heterogeneous_computing_environments_using_economic_resource_allocation_mechanisms?_tp=eyJjb250ZXh0Ijp7ImZpcnN0UGFnZSI6Il9kaXJlY3QiLCJwYWdlIjoiX2RpcmVjdCJ9fQ
https://www.researchgate.net/publication/259977469_Energy_conservation_in_distributed_heterogeneous_computing_environments_using_economic_resource_allocation_mechanisms?_tp=eyJjb250ZXh0Ijp7ImZpcnN0UGFnZSI6Il9kaXJlY3QiLCJwYWdlIjoiX2RpcmVjdCJ9fQ
Modelagem de Sistemas
O modelo pode ser definido como uma 
simplificação da realidade.
Fonte: agileapplied
Modelos fornecem 
uma cópia do projeto 
de um sistema 
Planos 
detalhados Planos Gerais
Modelagem de Sistemas
A modelagem definida como uma técnica para 
representar graficamente o comportamento e 
a estrutura de um sistema.
Estrutura de um 
sistema + 
Comportamento
Gráficos/Diagram
as
Modelagem
Técnica
Modelagem de Sistemas
Quanto maior e mais complexo for o 
sistema, maior será a necessidade da 
modelagem para compreender o 
sistema como todo.
Modelagem de Sistemas
Na área de software existem várias 
maneiras de se definir um modelo.
Modelagem Orientada a Objetos
Conceito de Orientação a Objetos
● Componente do mundo real que é 
mapeado para o domínio do software.
Conceito de Orientação a Objetos
● Pode representar uma entidade de 
natureza física ou conceitual.
Conceito de Orientação a Objetos
Classes:
É a representação de um conjunto de 
objetos similares (características).
Conceito de Orientação a Objetos
Classes:
Pode ser definida como Objetos que 
compartilham a mesma estrutura de 
atributos, operações e relacionamento, 
dentro de um mesmo contexto.
Conceito de Orientação a Objetos
Conteúdos da Aula de Hoje 
Conteúdos da Aula de Hoje 
Exemplos de Métodos:
● Inicializa o objeto
● Responsável por simular a ação 
Métodos (Comportamento):
● Os métodos manipulam os dados 
(atributos) da classe
Conteúdos da Aula de Hoje 
Elementos importantes na 
Orientação a Objetos
● Encapsulamento
● Herança 
● Polimorfismo
Conteúdos da Aula de Hoje 
 
● Herança 
Fonte:learn.microsoft.com/
● Polimorfismo
Utilizing BlueJ to Teach Polymorphism in an 
Advanced Object-Oriented Programming 
Course
O polimorfismo é a capacidade de diferentes 
classes desenvolverem (implementação) a 
mesma operação de maneira distinta. 
Utilizing BlueJ to Teach Polymorphism in an 
Advanced Object-Oriented Programming 
Course
Permitindo que os métodos ou operações 
sejam aplicados a diferentes tipos de 
objetos, mesmo que a implementação seja 
específica de cada tipo.
Utilizing BlueJ to Teach Polymorphism in an 
Advanced Object-Oriented Programming 
Course
Fonte:Unb
UML (do Inglês Unified Modeling 
Language) 
UML - Linguagem Unificada de 
Modelagem
https://en.wikipedia.org/wiki/Unified_Modeling_Language
https://en.wikipedia.org/wiki/Unified_Modeling_Language
UML 
Definição:
É um a linguagem gráfica para sistemas 
complexos:
● Visualização
● Especificação
● Construção
● Documentação de artefatos
UML 
É uma linguagem destinada a:
Verificar Construir
Especificar Documentar
UML 
UML - Blocos de Construção
O vocabulário UML abrange três tipos de 
blocos de construção:
1. Itens
2. Relacionamento
3. Diagramas
1. Itens
2. Relacionamento
3. Diagramas
São as abstrações 
identificadas como cidadãos 
de primeira classe do modelo
Responsável por 
reunir os itens
É responsável 
por agrupar 
coleções desses 
itens.
1. Itens
1. Itens estruturais
2. Itens Comportamentais
3. Itens de agrupamentos
4. Itens anotacionais
1. Itens1. Itens estruturais
1. Itens1. Itens estruturais
2. Relacionamento
1. Dependência 
2. Associação
3. Generalização
4. Realização
2. Diagramas
Um diagrama é a apresentação gráfica de 
um conjunto de elementos, geralmente 
representados como gráficos de vértice 
(itens) e arcos (relacionamentos).
2. Diagramas
1. Diagrama de Classes
2. Diagrama de objetos
3. Diagrama de componentes
4. Diagrama de estrutura composta
5. Diagrama de caso de uso
6. Diagrama de sequência
7. Diagrama de comunicações
8. Diagrama de gráficos de estados
9. Diagrama de atividades
10. Diagrama de implementação
11. Diagrama de pacote
12. Diagrama de temporização
13. Diagrama de visão geral da interação
2.1 Diagramas de Classes
Neste diagrama temos um conjunto de:
● Classes
● Interfaces 
● Colaborações
● Relacionamentos
2.1 Diagramas de Classes
Aplicação:
● Sistemas de Modelagem orientados a 
objetos
2.1 Diagramas de Classes
Objetivo:
● Permitir a visualização das classes que 
compõem o sistema com seus 
respectivos atributos e métodos.
2.1 Diagramas de Classes
Objetivo:
● Demonstrar como as classe do 
diagrama se relacionam, completam e 
transmitem a informações entre si.
2.1 Diagramas de ClassesObjetivo:
● Serve como apoio base para a 
construção da maioria dos outros 
diagramas da linguagem UML.
2.1 Diagramas de Classes
Relacionamento:
É possível compartilhar informações e 
participar da execução dos processos do 
sistema.
2.1 Diagramas de Classes
Relacionamento:
Tem como objetivo descrever um vínculo 
que ocorre entre os objetos de uma ou 
mais classes.
2.1 Diagramas de Classes
Relacionamento:
2.1 Diagramas de Classes
Relacionamento utilizando associação:
São os relacionamentos estruturais entre 
instâncias e especificam que objetos de 
uma classe estão ligados a objetos de 
outras classes. A associação pode ser 
unitária ou binária. 
Associação Unitária:
2.1 Diagramas de Classes
Relacionamento utilizando associação:
Associação binária: Quando existem 
duas classes envolvidas na associação 
de forma direta de uma para outra.
Multiplicidade Significado
0..1 No mínimo zero e no máximo um. Os 
objetos não precisam estar 
relacionados, porém se houver 
relacionamento deve ser de no 
máximo 1
1..1 Um e somente um
0..* No mínimo nenhum e no máximo 
muitos. 
* Muitos
1..* No mínimo um e no máximo muitos
3..5 No mínimo 3 e no máximo 5.
Explicação no Quadro
Fonte:cin.ufpe
Pedido deve saber qual Cliente fez o Pedido e o 
Cliente deve saber quais Pedidos foram feitos. 
Quando nenhuma seta for ilustrada, a associação é 
navegável nas duas direções.
No caso das associações entre o Cliente e o Endereço, 
o Cliente deve saber seus Endereços, mas os 
Endereços não têm conhecimento de quais Clientes a 
propriedade de navegabilidade da extremidade Cliente 
da associação é desativada.
Fonte:cin.ufpe
Um objeto da classe Sócio poderá chamar método da classe 
Dependente.
2.1 Diagramas de Classes
Herança ou Generalização:
Relacionamento entre um elemento mais 
geral e um mais específico. Onde o 
elemento mais específico herda as 
propriedades e métodos do elemento 
mais geral. 
2.1 Diagramas de Classes
Agregação:
Descreve que as informações de um 
objeto-todo precisam ser complementadas 
pelas informações contidas em um ou mais 
objetos-parte.
2.1 Diagramas de Classes
Composição:
Relacionamento entre um elemento ( o 
todo) e outros elementos (as partes) 
onde as parte só podem pertencer ao 
todo e são criadas e destruídas com ele.
2.1 Diagramas de Classes
Dependência:
Grau de dependência entre as classes 
(conexão entre classes é temporária). 
Se ocorrer mudança na classe principal, 
a classe dependente também muda.
2.2 Diagrama de Objetos
Um componente objeto é muitas vezes 
bastante semelhante a um componente 
classe, mas os objetos não contém 
métodos, apenas atributos.
2.2 Diagrama de Objetos
O nome dos objetos está contido, como 
nas classes, na primeira divisão do 
retângulo que representa os objetos e 
pode ser apresentado de trê forma:
2.2 Diagrama de Objetos
1. O nome do objeto, com todas as letras maiúsculas, 
seguido do símbolo de dois pontos(:) e o nome da 
classe à qual o objeto pertence, com as letras iniciais 
maiúsculas. 
2. O nome do objeto omitido, mas mantendo o símbolo 
de dois-pontos e o nome da classe.
3. Somente o nome do objeto, sem dois-pontos.
2.2 Diagrama de Objetos
2.2 Diagrama de Objetos
2.2 Diagrama de Objetos
Vínculos:
Os objetos de um diagrama de objetos 
apresentam vínculos entre sí (links).
2.3 Diagrama de Caso de Uso
O diagrama de Casos de Uso tem como 
objetivo possibilitar a compreensão do 
comportamento externo do sistema (em 
termos de funcionalidades oferecidas 
por ele).
Os atores representam os 
papéis desempenhados pelos 
diversos usuários que poderão 
utilizar, de alguma maneira, os 
serviços e funções do sistema.
Atores
Como identificar os atores?
● Que tipo de usuários poderão utilizar o 
sistema?
● Quais usuários estão interessados ou 
utilizarão quais funcionalidades e 
serviços do software?
2.3 Diagrama de Caso de Uso
● Quem fornecerá informações aos 
sistema?
● Quem utilizará as informações do 
sistema?
● Quem poderá alterar ou mesmo excluir 
informações do sistema?
2.3 Diagrama de Caso de Uso
● Existe algum software que interage 
com o sistema?
● Existe algum hardware especial (como 
robô, por exemplo) que irá interagir 
com o software?
Casos de Uso
Os casos de uso são 
utilizados para capturar 
os requisitos funcionais 
do sistema
Casos de Uso
● Serviços
● Funcionalidades identificados como 
necessários ao software 
Como identificar os Casos de Uso?
Para identificar os casos de uso que fará 
parte do modelo, é necessário determinar 
as funcionalidades necessárias do 
software.
Como identificar os Casos de Uso?
Todas as funções e serviços que 
correspondem aos requisitos funcionais 
declaradas pelos stakeholders como 
necessários ao sistema.
Associação
Generalização/Especialização
Generalização/Especialização
Inclusão
É utilizada quando existe um cenário, 
situação ou rotina comum a mais de um 
caso de uso.
Inclusão
É colocada em um caso de uso 
específico para que outros casos de uso 
utilizem esse serviço, evitando 
descrever a mesma sequência.
Extensão
São utilizadas para descrever cenários 
opcionais que podem ser estendidos 
pelos comportamentos de outros casos 
de uso.
Extensão
Os casos de uso estendidos descrevem 
cenários que apenas serão executados em 
situações específicas quando determinadas 
condições forem satisfeitas.
Extensão
Extensão
Extensão
Restrições em Associação de Extensão
São compostas de um texto entre chaves 
e utilizadas para definir validação, 
consistências que devem ser aplicada a 
um determinado componentes ou 
situação.
Restrições em Associação de Extensão
Restrições em Associação de Extensão
Pontos de Extensão
Um ponto de extensão identifica um ponto no 
comportamento de um caso de uso a partir 
do qual esse comportamento poderá ser 
estendido pelo comportamento de outro caso 
de uso, se a condição para que isso ocorra 
for satisfeita.
Pontos de Extensão
Multiplicidade no Diagrama de Casos de 
Uso
Especifica o número de vezes que um 
ator pode utilizar um determinado caso 
de uso.
Multiplicidade no Diagrama de Casos de 
Uso
(Só pode ser utilizado por um sócio e um 
funcionários por vez)
Multiplicidade no Diagrama de Casos de 
Uso
● Ator sócio utiliza o caso de uso Cadastrar 
Sócio somente uma vez.
● Ator funcionário pode utilizar muitas 
vezes.
Estereótipos
Fronteiras de
Sistema
Referência Bibliográfica
Booch, Grady, and Rumbaugh, James. UML: guia do 
usuário. Brasil, Elsevier, 2006.
UML 2 – Guia Prático - 2ª Edição. Brasil, Novatec Editora, 
2014.
Guedes, Gilleanes T. A.. UML 2 - Uma Abordagem Prática. 
Brasil, Novatec Editora, 2018.
Referência Bibliográfica
Exercitando Modelagem em UML. N.p., Brasport.
Larman, Craig. Utilizando UML e Padrões. Brasil, 
Bookman, 2007.
Desenvolvendo Aplicações com UML 2.2. N.p., Brasport.
Atividade de Aprendizagem