Resumo das aulas 1 a 10 - MODELAGEM DE SISTEMAS

Prévia do material em texto

MODELAGEM DE SISTEMAS
Aula 1
RUP
Princípios: 	Feedback
		Transparência
		Comunicação
Fases:
Iniciação ou Concepção: ênfase no escopo do sistema;
Elaboração: ênfase na arquitetura;
Construção: ênfase no desenvolvimento;
Transição: ênfase na implantação.
Fase de Concepção – Marco Escopo
A fase de iniciação ou concepção contém os workflows necessários à concordância dos stakeholders - as partes interessadas - com os objetivos, a arquitetura e o planejamento do projeto. Se essas partes interessadas tiverem bons conhecimentos, pouca análise será requerida. Caso contrário, será exigida uma análise mais elaborada. Nesta fase, os requisitos essenciais do sistema são transformados em casos de uso. O objetivo não é fechá-los em sua totalidade, mas apenas aqueles necessários à formação de opinião. A etapa é geralmente curta e serve para definir se é viável continuar com o projeto e definir os riscos e o custo deste último. Um protótipo pode ser feito para que o cliente possa aprovar. Como cita o RUP, o ideal é que sejam feitas iterações, mas estas devem ser bem definidas quanto à sua quantidade e aos objetivos.
Fase de Elaboração – Marco Arquitetura
A fase de elaboração será apenas para o projeto do sistema, buscando complementar o levantamento / documentação dos casos de uso, voltado para a arquitetura do sistema, revisa a modelagem do negócio para os projetos e inicia a versão do manual do usuário. Deve-se aceitar: Visão geral do produto (incremento + integração) está estável?; O plano do projeto é confiável?; Custos são admissíveis?
Fase de Construção – Marco Desenvolvimento
Na fase de construção, começa o desenvolvimento físico do software, produção de códigos, testes alfa. Os testes beta são realizados no início da fase de Transição.
Deve-se aceitar testes, e processos de testes estáveis, e se os códigos do sistema constituem "baseline".
Fase de Transição – Marco implantação, release
Nesta fase ocorre a entrega ("deployment") do software, é realizado o plano de implantação e entrega, acompanhamento e qualidade do software. Produtos (releases, versões) devem ser entregues, e ocorrer a satisfação do cliente. Nesta fase também é realizada a capacitação dos usuários.
Aula 2
UML: é um conjunto de diagramas padronizados e integrados para ajudar na descrição da análise e projeto de um software.
A orientação a objetos tem-se desenvolvido  desde o lançamento da 1ª linguagem orientada a objetos, a SIMULA. É uma tecnologia de eficiência e qualidade comprovadas.
Benefícios da tecnologia orientada a objetos:
Melhor reaproveitamento de seu código (até mesmo em outros sistemas)
Facilidade de manutenção
Melhor compreensão do código
Mais segurança no uso de componentes por parte do programador
Diagramas Estáticos (estrutura):
1. Diagrama de Classes
2. Diagrama de Componentes
3. Diagrama de estrutura composta
4. Diagrama de Objetos
5. Diagrama de Implantação
6. Diagrama de Artefatos
Diagramas Dinâmicos (comportamento):
1. Diagrama de caso de uso
2. Diagrama de sequências
3. Diagrama de comunicação
4. Diagrama de gráfico de estados
5. Diagrama de atividades
Diagrama Caso e Uso
Requisitos: São as necessidades dos usuários, as funcionalidades necessárias para realizar o negócio.
Funcionais: ligados a produção da aplicação.
Não-funcionais: necessidades de ambiente e estrutura operacional (operacionalidade, ambiente operacional, etc.);
 <<INCLUDE>> = Estereótipos
Os bonecos são chamado s de ator. É a representação do responsável por realizar o caso de uso. Um ator pode ser uma pessoa, um órgão ou mesmo um sistema.
O desenho da elipse representa um conjunto de ações humanas. Esse conjunto de atividades é chamado de comando de utilização.
A linha pontilhada representa a dependência. Que neste caso significa que a elipse de identificar pedido só pode existir se existirem as outras duas elipse.
Dicionário:
Uso de Estereótipo
Usado nas interações entre os casos de uso.
<<INCLUDE>> Relacionamento com outro caso de uso que sempre será executado. 
Um caso de uso, para ter sua funcionalidade executada, precisa chamar outro caso de uso. Estabelece a ligação obrigatória entre os casos de uso. SEMPRE o caso de uso será executado. É comum, também, se usar << use >>, com as mesmas características.
<< EXTENDED>> Relacionamento com outro caso de uso que pode ou não ser executado. 
Esta relação significa que o caso de uso estendido vai funcionar exatamente como o caso de uso base só que alguns passos novos inseridos no caso de uso extendido. A ligação opcional entre os casos de uso. O caso de uso será executado em atendimento a uma regra de negócio.
<< INTERFACE>> é o arco entre o ator e o comando de utilização, nesse caso se informa que o tratamento de chamada deve ser feito do mesmo modo, por exemplo: com telas de entrada.
Você pode criar o seu próprio estereótipo, o importante é que se apresente o dicionário de estereótipos.
Aula 3
Diagrama de classes
O diagrama é como uma fotografia dos elementos usados pela aplicação.  É uma representação estática (estrutural) e não deve ser usado para representar dinâmicas da aplicação, embora também as retrate.
Classe: é um conjunto de objetos com características similares.
Quando os atributos de uma classe recebem valor, dizemos que a classe foi INSTANCIADA.
Classes Dependentes: Existem alguns conjuntos que, no processo de modelagem, desejamos condicioná-los à existência de outros conjuntos. São chamados de conjuntos dependentes. Um objeto dependente só pode ser dependente de um único objeto.
Associações: Uma associação é um conjunto criado com objetivo de ligar outros dois (ou mais) conjuntos existentes.
As classes associadoras são representadas por linhas cheias e a classe que as associa é ligada a esta linha cheia por uma linha pontilhada.
Aula 4
OBJETO: todo elemento que representa ou compõe algum conceito dentro de nosso projeto. 
CLASSE: conjunto de objetos com atributos e comportamentos representados por métodos. Ex.: Classe CLIENTES representa todos os clientes da empresa.
ATRIBUTO: característica ou identificação do objeto. Ex.: nome, cpf, email, ...
MÉTODOS: operações realizadas para um objeto. Ex.: lerNome()
ASSOCIAÇÃO ligação estabelecida entre as classes, por necessidade de comportamentos do negócio analisado. Quando tem-se uma regra que define a ligação entre objetos de classes diferentes.
PAPEL nome da associação, tornando claro no diagrama a ligação estabelecida.
MULTIPLICIDADE define o número de vezes em que o objeto participa da associação.
A representação de multiplicidade possui o seguinte esquema: 
Li ... Ls, onde: 	Li define o Limite inferior 
 Ls define o Limite superior
Li e Ls poderão ter valores numéricos de 0 a n 
Ls poderá também ter a representação * que tem como significado infinito/muitos.
SE O OBJETO PUDER EXISTIR SEM PARTICIPAR DA LIGAÇÃO O LI É 0.
CLASSE ASSOCIATIVA: Classe que representa os objetos resultados de uma associação, com atributos, características e operações próprias.
RESTRIÇÕES: Complementam o modelo com informações não representadas. 
AGREGAÇÃO POR REFERÊNCIA: Define o conceito <compõe> e associa os objetos indicando que existe referência para várias participações. Sempre sera de 1 para * .
AGREGAÇÃO POR VALOR: Define o conceito <estar inserido> associando os objetos indicando que existe referência para apenas uma participação e estabelece uma dependência entre as classes associadas. 
 Ex A classe Dependentes só existe se tiver Cliente cadastrado.
Aula 5
AUTO ASSOCIAÇÃO: Define quando um objeto de uma classe está relacionado com outro objeto da mesma classe para atender a algum comportamento. A multiplicidade é estabelecida normalmente.
GENERALIZAÇÃO: Representa os vários tipos de um objeto em uma única classe.
ESPECIALIZAÇÃO: Representa os vários tipos de um objeto em uma classe distinta relacionando seus próprios atributos e comportamentos. 
Atributose comportamentos comuns são relacionados na classe mãe.
Diagrama de sequência
O diagrama se sequencia mostra, quais as classes e como (através de que métodos) essas classes realizam as funcionalidades de um determinado caso de uso. 
Mostra a sequência de chamada de métodos (MENSAGENS) ao longo do tempo. Um diagrama de sequência mostra a sequência de execução de funções, portanto, não mostra troca de informação. Um diagrama de sequência é uma espécie de algoritmo de alto nível em que se destaca a chamada das funções.
Métodos: Um método é uma função que colocamos dentro da classe, isto quer dizer que a função está encapsulada e só pode ser executada a partir da classe.
Mensagem: Os objetos precisam trabalhar de forma coordenada, e por isto devem se comunicar através de seus métodos. Um objeto pode chamara a execução de um método de outro objeto. A chamada do método de outra mensagem é o que chamamos de mensagem.
Aula 6
Diagrama de colaboração
Mostra como as classes se colaboram. O diagrama de colaboração expressa, de forma diferente, as mesmas informações do diagrama de sequência. O diagrama de colaboração mostra uma interação organizada em torno de um conjunto limitado de objetos, por isto é, normalmente, preferido pelos programadores.
Escolher o diagrama de colaboração, quando o objeto e seus vínculos facilitam a compreensão da iteração e escolher o diagrama de sequência apenas se a sequência precisa ser evidenciada. (Furlan)
As classes, definidas para apresentação, poderão ser marcadas com o estereótipos de apresentação ou “view”.
As classes definidas como “controles” contém o código que permite controlar a instanciação de novas classes ou mesmo ordenar como será executado um método. Entre um objeto de apresentação e um objeto de negócios sempre deverá existir um objeto de controle, isto dará mais reutilização ao código.
As classes de negócio, que são originarias da análise e onde se têm as regras de negócio.
Um padrão de projeto é uma solução já estabelecida para um determinado problema. O padrão tem uma sintaxe da forma:
Nome do padrão:
Problema que resolve:
Solução:
Padrão de projeto GRASP: definiem princípios gerais para atribuição de responsabilidades das classes. Existem 05 padrões: 
Especialista na informação (Information Expert) - Atribuir a responsabilidade do método à classe que tem a informação, isto é, onde existe o atributo.
Creator - Responsável pela criação de uma nova instância de um objeto
Coesao Alta - Manter o acoplamento fraco entre classes e manter uma alta coesão nas classes deve ser o objetivo de um projeto
Acoplamento Fraco - Atribuir responsabilidades de modo que a dependência entre elementos fique o mais baixa possível.
Controlador - Criar uma classe responsável por tratar o evento.
Aula 7
Diagramas de componentes 
Um componente pode ser tanto um código em linguagem de programação como um código executável já compilado. Por exemplo, em um sistema desenvolvido em Java, cada arquivo .java ou .class é um componente do sistema, e será mostrado no diagrama de componentes que os utiliza.
Um componente se representa graficamente na forma:
 
Um componente é uma parte física e substituível de um sistema com o qual está em conformidade e proporciona a realização de um conjunto de artefatos (UML).
O diagrama de componente mostra o sistema pelo seu lado funcional, mostrando a organização de seus módulos e como se dará a sua execução. 
Portanto, representa o desenho da estrutura do código gerado.
Podemos escrever um módulo, a ser compilado dentro do componente, que verifique as suas condições de execução.  Ou seja, verifica se existem os outros componentes necessários para o seu trabalho, ou faz o controle dos métodos ou interfaces que estão sendo usados.  Este módulo é um controle e é chamado de controle do componente.
Diagrama de implantação (ou Execução)
Mostra a organização do hardware e a ligação do software aos dispositivos físicos.
O diagrama é constituído de nós conectados.
Um nó representa um dispositivo físico com memória ou capacidade de processamento.
Aspectos para se alocar componentes em um nó:
Segurança: Estabelecer direitos de acesso e proteção de dados em localizações geográficas diferentes.
Acesso a dispositivos: Avaliar as necessidades individuais de dispositivos em um nó, incluindo conexão de impressoras e demais periféricos.
Localização geográfica: Determinar que funcionalidades necessitam estar disponibilizadas localmente para o melhor desempenho.
Utilização de recursos: Distribuir componentes de forma a obter desempenho máximo do hardware utilizado.
O diagrama de execução mostra instâncias de nós que significam objetos físicos que fazem parte do sistema, podendo ser uma máquina cliente numa LAN, uma máquina servidora, uma impressora, um roteador, etc., e conexões entre estes nós e componentes que juntos compõem toda a arquitetura física do sistema.
Aula 8
Diagrama de Estado
O Diagrama de Estado na UML é utilizado para apresentar os estados, a mudança de estado e o processo que faz mudar o estado de um Caso de Uso ou de uma Classe.
Tem a finalidade de exibir como um objeto realiza uma determinada operação num determinado momento da execução, representando um estado particular. 
Estado: Posição do objeto após a ocorrência da transição.
Atividade: Procedimento desenvolvido até que ocorra a transição.
Transição: Ocorrência para mudança de estado.
Evento: Fato ocorrido para provocar a transição.
Guarda: Condição lógica. Transição guardada ocorre somente se a guarda for “verdade”.
Ação: Procedimento responsável por alterar o status.
Simbologia – Auto transição
Quando houver uma transição que retorna ao mesmo estado.
Simbologia – Super Estados
Quando um conjunto de atividades define ao final o mesmo estado.
Simbologia – Estados Concorrentes
Quando um objeto de uma mesma classe pode ter mais de um estado ao mesmo tempo para que ao final tenha um só estado. O estado final só será atingido SE ambos os estados forem confirmados.
Aula 9
Diagrama de Atividade
O diagrama de atividade permite escolher a ordem pela qual as coisas devem ser feitas, isto é, indica meramente as regras essenciais de sequência que necessitam ser seguidas - esse é um aspecto fundamental para diferenciar um diagrama de atividade de um fluxograma. 
Fluxogramas são limitados a processos seqüenciais enquanto que Diagramas de Atividade podem manipular processos paralelos.
Diagramas de atividade capturam ações e seus resultados de casos e usos. O seu objetivo é o de capturar ações e seus resultados em termos das mudanças de estados dos objetos.
Um diagrama de atividade é uma maneira alternativa de se mostrar interações, que ocorrem em um caso e uso com a possibilidade de expressar que ações são executadas.
Um diagrama de atividade pode ser usado com diferentes propósitos inclusive:
Para capturar os trabalhos que serão executados quando uma operação é disparada (ações). Este é o uso mais comum para o diagrama de atividade.
Para capturar o trabalho interno em um objeto.
Para mostrar como um grupo de ações relacionadas pode ser executado, e como elas vão afetar os objetos em torno delas.
Para mostrar como uma instância pode ser executada em termos de ações e objetos.
Para mostrar como um negócio funciona em termos de trabalhadores (atores), fluxos de trabalho, organização, e objetos (fatores físicos e intelectuais usados no negócio).
Aula 10 - Tópicos especiais
Visibilidade de atributos
Uma classe é encapsulada para proteger seus dados e métodos. Assim quando se especifica um método ou uma classe eles devem ser protegidos quanto ao acesso, mas muitas vezes precisamos acessar estes dados ou métodos de fora da classe. Assim neste tópico vamos analisar como isto é tratado.
Privado (private)
É a condição de criação de um método ou atributo. Significa que só podem ser usados dentro da classe onde estão especificados. Os métodos podem utilizar diretamente as variáveisou outros métodos internos à classe, são considerados como globais no escopo da classe. Quando não se especifica o tipo de atributo assume-se como privado.
Publico (public)
Quando explicitamente se deseja liberar o acesso feito de forma externa a classe. Não é uma situação desejável, pois é contra o conceito de implementação de uma classe, que é de proteger de forma encapsulada seus métodos e atributos. 
Protegido (protected)
Só deve ser usado quando temos uma estrutura gen-esp. Quando um método ou atributo é especificado como protected ele é visível por todas as classes que estão na estrutura GEN-ESP.
Podem-se abrir os métodos de uma classe A para uma classe B declarando que a Classe B é amiga de A. Neste caso você pode considerar que os métodos e atributos privados A são totalmente visíveis para B. Ex: Classe A friend classe B;
UML usa a seguinte notação na frente do atributo ou método:
+ significa que o método ou atributo é público (public)
- significa que o método ou atributo é privado (private)
# significa que o método ou atributo é protegido (protected)
Visibilidade de objetos
Visibilidade é a capacidade de um objeto fazer referencia e utilizar métodos e valores de outro objeto.
Diagrama de pacotes
Um pacote é um recurso para definição de grupamentos. Seu uso mais comum é o grupamento de classes, embora possa se fazer grupamentos para tipos de elementos no UML. É um recurso que pode ser usado para organizar o sistema seja pelo aspecto tecnológico ou administrativo.
Os pacotes podem ser membros de outros pacotes. Pode-se definir uma hierarquia de pacotes. Um pacote pode conter um ou mais pacotes e assim sucessivamente.
Se o conteúdo do pacote é exibido deve-se colocar o nome na aba, senão for pode-se colocar o nome no meio do meio do retângulo. Se for necessário, ainda, pode-se usar o recurso de estereótipo usando a indicação “<<” e “>>” com o nome dado.
Uma classe X definida dentro de um pacote em a seguinte sintaxe:
  NomeDoPacote :: NomeDaClassse
 
Se for necessário uma classe pode incluir um caminho completo de pacote no qual está presente. Se forem pacotes encadeados deve-se grupar os nomes dos pacotes separados por:
Nomedopaacote1::NomeDo Pacote2::NomeDoPacote3::NomeDaClasse
Um pacote não pode modificar atributos ou métodos de uma classe. Um pacote deve ter sua visibilidade indicada para os outros pacotes (como podem acessá-lo).
Visibilidade de pacotes
A visibilidade de um pacote pode ser:
Privada: Somente o pacote que possui o elemento pode usá-lo.
Protegida: Além dos elementos do pacote é possível que pacotes que participem de generalização acessem.
Pública: Todos os elementos podem acessar o conteúdo do pacote. É o default quando nada é indicado.
Implementação: Similar a visibilidade privada, mas os elementos de modelos que têm uma dependência com um pacote não podem usar os elementos dentro daquele pacote.
Dentro de um pacote as classes são públicas ou privadas. Se uma classe de um pacote precisa ser usada por outra classe de um outro pacote estabelece-se uma dependência entre os pacotes.
Na grande maioria dos casos, os pacotes possuem relacionamentos com outros pacotes. Embora estes não possuam semânticas definidas para suas instâncias. Os relacionamentos permitidos entre pacotes são de dependência, refinamento e generalização (herança).
Se um pacote for destruído, todo o seu conteúdo também será.
1. Descrição de Caso de Uso: Descreve a funcionalidade do sistema percebida por atores externos. 
5. Diagrama de Seqüência: Apresenta objetos e classes envolvidas no cenário e a seqüência de mensagens trocadas entre os objetos; 
6. Diagrama de Atividades: Representa o processo descrevendo as atividades seqüenciais e paralelas. 
4. Diagrama de Estado: Descreve os estados possíveis em que um objeto pode se encontrar e o que muda como resultado de eventos que o atingem. 
3. Diagrama de Classe: Descreve os tipos de objetos no sistema e os vários tipos de relacionamento estático que existem entre eles. 
2. Diagrama de Caso de Uso: Representa os requisitos do sistema.