aula 2 slide

Prévia do material em texto

MODELAGEM DE 
SISTEMAS 
AULA 02
TÓPICOS
• UML
Modelagem de sistemas
• A modelagem de sistemas de software consiste na utilização de notações
gráficas e textuais com o objetivo de construir modelos que representam as
partes essenciais de um sistema, considerando-se várias perspectivas
diferentes e complementares
• Porque usar modelos na construção de sistemas:
 Gerenciamento da complexidade
 Comunicação entre as pessoas envolvidas
 Redução dos custos no desenvolvimento
 Previsão do comportamento futuro do sistema
Orientação a Objetos
• O paradigma da orientação a objetos visualiza um sistema de software como
uma coleção de agentes interconectados chamados objetos.
• Cada objeto é responsável por realizar tarefas específicas.
• É pela interação entre objetos que uma tarefa computacional é realizada
Sistemas OO
• Um sistema de software orientado a objetos consiste em objetos em 
colaboração com o objetivo de realizar as funcionalidades desse sistema
• Cada objeto é responsável por tarefas específicas
• É graças a cooperação entre objetos que a computação do sistema se 
desenvolve
RUP
• O RUP, abreviação de Rational Unified Process (ou Processo Unificado Rational), é um
processo proprietário de Engenharia de software criado pela Rational Software Corporation,
adquirida pela IBM, ganhando um novo nome IRUP que agora é uma abreviação de IBM
Rational Unified Process e tornando-se uma brand na área de Software, fornecendo técnicas
a serem seguidas pelos membros da equipe de desenvolvimento de software com o objetivo
de aumentar a sua produtividade no processo de desenvolvimento.
• O RUP usa a abordagem da orientação a objetos em sua concepção e é projetado e
documentado utilizando a notação UML (Unified Modeling Language) para ilustrar os
processos em ação. Utiliza técnicas e práticas aprovadas comercialmente.
• É um processo considerado pesado e preferencialmente aplicável a grandes equipes de
desenvolvimento e a grandes projetos, porém o fato de ser amplamente customizável torna
possível que seja adaptado para projetos de qualquer escala. Para a gerência do projeto, o
RUP provê uma solução disciplinada de como assinalar tarefas e responsabilidades dentro
de uma organização de desenvolvimento de software, é, por si só, um produto de software. É
modular e automatizado, e toda a sua metodologia é apoiada por diversas ferramentas de
desenvolvimento integradas e vendidas pela IBM através de seus "Rational Suites".
Métodos concorrentes no campo da engenharia de software incluem o "Cleanroom"
(considerado pesado) e os Métodos Ágeis (leves) como a Programação Extrema (XP-Extreme
Programming), Scrum, FDD e outros.
UML 
• Linguagem padrão da OMG (http://www.omg.org/) 
• O Object Management Group® (OMG®) é um consórcio de padrões de 
tecnologia sem fins lucrativos e de associação aberta internacional.
• Fundada em 1989, os padrões OMG são direcionados por fornecedores, 
usuários finais, instituições acadêmicas e agências governamentais. As 
Forças-tarefa OMG desenvolvem padrões de integração empresarial para 
uma ampla gama de tecnologias e uma gama ainda maior de indústrias.
• http://www.omg.org/spec/UML/
Segundo Craig Larman em seu livro : 
Utilizando UML e Padrões 
Perspectivas em UML
Modelagem visual segundo Craig 
Larman
Breve histórico
EVOLUÇÃO DA UML
Artigo 
• https://projetos.inf.ufsc.br/arquivos_projetos/projeto_721/artigo.tcc.pdf
• Documentação atual:
• http://www.omg.org/spec/UML/2.4.1/
Para que serve a UML
• Visualização
• Especificação
• Construção
• Documentação 
• ...de softwares orientados a objetos
Visualização
• A existência de um modelo visual facilita a comunicação e faz com que os 
membros de um grupo tenham a mesma idéia do sistema.
• Cada símbolo gráfico tem uma semântica bem definida.
Especificação
• É uma ferramenta poderosa para a especificação de diferentes aspectos 
arquiteturais e de uso de um sistema.
Construção
• Geração automática de código a partir do modelo visual
• Geração do modelo visual a partir do código
• Ambientes de desenvolvimento de software atuais permitem:
– movimentações em ambos sentidos e
– manutenção da consistência entre as duas visões.
Documentação
• Pode incluir artefatos como:
• Deliverables (documentos como especificação de requisitos, especificações funcionais, 
planos de teste, etc.).
• Materiais que são importantes para controlar, medir, e refletir sobre um sistema 
durante o seu desenvolvimento e implantação.
Descrição Arquitetônica
• UML oferece uma forma padrão de se desenhar as “plantas” (como em 
arquitetura) de um sistema de forma a incluir:
• aspectos abstratos (processos de negócio, funcionalidades do sistema)
• aspectos concretos (classes C++/Java esquemas de bancos de dados, componentes de 
software reutilizáveis)
Razões para Modelar
• Comunicar a estrutura e o comportamento desejado de um sistema.
• Visualizar e controlar a arquitetura de um sistema.
• Para melhorar o nosso entendimento de um sistema e, assim, expor 
oportunidades para melhorias e reutilização.
• Para administrar os riscos e trade-offs.
• A UML não é um método de
desenvolvimento, ela não diz para
você o que fazer primeiro e em
seguida ou como desenhar seu
sistema, mas ela lhe auxilia a
visualizar seu desenho e a
comunicação entre objetos.
VISÃO GERAL- POR QUE MODELAR?
Princípios da Modelagem
• A escolha dos modelos a serem criados tem profunda influência sobre a 
maneira como um determinado problema é atacado e como uma solução é 
definida
• Cada modelo poderá ser expresso em diferentes níveis de precisão
• Os melhores modelos estão relacionados à realidade
• Nenhum modelo único é suficiente.
• Qualquer modelo não-trivial será melhor investigado por meio de um 
pequeno conjunto de modelos quase independentes
Objetivos da Modelagem
• Compreender melhor o sistema que estamos desenvolvendo 
• Visualizar o sistema
• Documentar decisões tomadas
• Especificar comportamento ou a estrutura de um sistema
A UML não é
• Um processo
• Uma metodologia
• Análise e projeto OO
• Regras de projeto
DEFINIÇÃO
UML é uma linguagem padrão para
elaboração da estrutura de projetos de
software
UML é adequada a modelagem de sistemas
UML é apenas uma linguagem e, portanto,
é somente uma parte de um método para o
desenvolvimento de software.
Elementos principais
•Blocos de Construção
•Regras
•Mecanismos
MODELO CONCEITUAL
• Itens
Estruturais
Comportamentais
Agrupamento
Anotacionais.
BLOCOS DE CONSTRUÇÃO DA 
UML
Relacionamentos
Dependência
Associação
Generalização
Realização.
Classes
Objetos
Casos de Uso
Seqüências
Colaborações
Gráficos de estados
Atividades
Componentes
Implantação
Diagramas
• Itens são os blocos de construção básicos orientados a objetos 
da UML. São utilizados para escrever modelos bem formados
• Os relacionamentos reúnem Itens
• Os diagramas agrupam coleções de Itens
ITENS EM UML
ITENS EM UML
Itens Estruturais
São os substantivos utilizados. Representam a parte mais estática do
modelo, os elementos conceituais ou fisicos. Ao todo existem sete tipos
de itens estruturais
ITENS ESTRUTURAIS
Classe
Caso de UsoColaboraçõesInterface
Classe Ativa
Componentes
Nós
ITENS EM UML
Itens Comportamentais
São as partes dinâmicas dos modelos de UML
São verbos de um modelo representando comportamento no tempo e
no espaço
ITENS COMPORTAMENTAIS
 Interação: Comportamento que abrange um conjunto
de mensagens trocadas entre objetos num contexto
específico
Máquina de estados: Especifica as seqüências de
estados pelas quais objetos e interações passamdurante sua existência em resposta a eventos.
Itens de Agrupamento
São partes organizacionais dos modelos de UML. Servem para a
organização de elementos (como itens estruturais ou
comportamentais) em grupos.
ITENS EM UML
PACOTES
TENS DE AGRUPAMENTO
ITENS ANOTACIONAIS
•Itens Anotacionais
São partes explicativas dos modelos de UML
São comentários, incluídos para descrever,
esclarecer e fazer alguma observação sobre
qualquer elemento do modelo.
NOTNOTAS
• Itens
Estruturais
Comportamentais
Agrupamento
Anotacionais.
BLOCOS DE CONSTRUÇÃO DA 
UML
Relacionamentos
Dependência
Associação
Generalização
Realização.
Classes
Objetos
Casos de Uso
Seqüências
Colaborações
Gráficos de estados
Atividades
Componentes
Implantação
Diagramas
RELACIONAMENTOS EM 
UML
• São blocos relacionais básicos de construção da UML. Como os
Itens, os relacionamentos são utilizados para escrever modelos
bem-formados.
 Relacionamento de Dependência
 Relacionamento de Associação
 Relacionamento de Generalização
 Relacionamento de Realização
RELACIONAMENTO DE 
DEPENDÊNCIA
• É um relacionamento semântico entre dois itens nos quais a
alteração de um (o item independente) pode afetar a semântica
do outro item (o item dependente).
É um relacionamento estrutural
que descreve um conjunto de
ligações
São conexões entre objetos
Agregação é um tipo especial de
associação
RELACIONAMENTO DE ASSOCIAÇÃO
0..1 * 
Empregador Funcionário
RELACIONAMENTO DE 
GENERALIZAÇÃO
• É um Relacionamento de
especialização nos quais os objetos
dos elementos especializados
(filhos) são substituíveis por objetos
do elemento generalizado (pais).
RELACIONAMENTO DE 
REALIZAÇÃO
É um relacionamento semântico entre
classificadores, em que um classificador
especifica um contrato que outro
classificador garante executar. São
encontrados em dois lugares:
Entre interfaces e as classes ou
componentes que as realizam
Entre casos de uso e as colaborações
que os realizam
• Itens
Estruturais
Comportamentais
Agrupamento
Anotacionais.
BLOCOS DE CONSTRUÇÃO DA 
UML
Relacionamentos
Dependência
Associação
Generalização
Realização.
Classes
Objetos
Casos de Uso
Seqüências
Colaborações
Gráficos de estados
Atividades
Componentes
Implantação
Diagramas
DIAGRAMAS EM UML
• São apresentações gráficas de um
conjunto de elementos
• São desenhados para permitir a
visualização de um sistema sob
diferentes perspectivas
• Apresenta uma visão parcial dos
elementos que compõe o sistema
• O mesmo elemento pode aparecer
em vários diagramas (todos, alguns
ou em nenhum).
DIAGRAMAS EM UML
Diagrama de Classes
Diagrama de Objetos
Diagrama de Casos de Uso
Diagrama de Sequências
Diagrama de Colaborações
Diagrama de Gráficos de Estados
Diagrama de Atividades
Diagrama de Componentes
Diagrama de Implantação
DIAGRAMAS EM UML
DIAGRAMAS EM UML
DIAGRAMA DE CLASSES
 Exibe conjunto de classes,
interfaces e colaborações, bem
como seus relacionamentos.
 Mostram uma visão estática do
sistema.
DIAGRAMA DE CLASSES
DIAGRAMA DE CLASSES
DIAGRAMA DE CASOS DE USO
DIAGRAMA DE CASOS DE USO
Caso de Uso: Ou Use Case, é
uma sequencia de ações que o
sistema executa e produz um
resultado de valos para o ator.
Modela o diálogo entre
atores e o sistema
É um fluxo de eventos
completo e consistente
O conjunto de todos os Use
Case representa todas as
situações possíveis de
utilização do sistema.
Ator ou Usuário: Qualquer
entidade que interage com o
ativa ou passivamente com o
Sistema.
Pode ser uma pessoa, ouro
sistema ou máquina.
Não é parte do sistema.
Representa papéis que o
usuário pode desempenhar.
DIAGRAMA DE CASOS DE USO
Elementos principais
•Blocos de Construção
•Regras
•Mecanismos
MODELO CONCEITUAL
REGRAS NA UML
Nomes:
Quais nomes podem ser atribuídos a coisas, relacionamentos e diagramas
Escopo:
O contexto que determina um significado específico para um nome
REGRAS NA UML
Visibilidade:
Como estes nomes podem ser vistos 
e utilizados pelos outros
Integridade:
Como os itens se relacionam entre si 
de forma adequada e consistente
Execução:
O que significa executar ou
simular um modelo semântico
Elementos principais
•Blocos de Construção
•Regras
•Mecanismos
MODELO CONCEITUAL
MECANISMOS
• Especificações: fornece declaração textual da sintaxe e
semântica do respectivo bloco de construção.
• Adornos: São os simbolos básicos que iniciam todos os
elementos da notação da UML.
• Divisões comuns: Pode dividir classes e objetos ou
interface e implementação
Permite aos usuários estender a linguagem de
maneira controlada.
• Estereótipos, Restrições e Valores Atribuídos
são os mecanismos de extensibilidade fornecidos
pela UML para permitir adicionar novos blocos de
construção, criar novas propriedades e espcificar
nova semântica.
MECANISMOS DE EXTENSÃO
CONSIDERAÇÕES
Vale a pena dizer que a UML é muito
mais que a padronização de uma
notação, é o desenvolvimento de novos
conceitos. Por essa razão entender UML
não é apenas aprender a ler uma
simbologia, mais significa aprender a
modelar orientando a objetos.
Visão de casos de uso
• Descreve o sistema de um ponto de 
vista externo como um conjunto de 
interações entre o sistema e os 
agentes externos ao sistema
• É uma visão criada inicialmente e 
direciona o desenvolvimento das 
outras visões do sistema
Visão de projeto (Lógica)
• Analistas e desenvolvedores
• Ligada ao problema do negócio
• Enfatiza as características do sistema 
que dão suporte tanto estrutural 
quanto comportamental, às 
funcionalidades externamente visíveis 
do sistema
• Coleção de pacotes, classes e 
relacionamentos
Visão de implementação (de 
componente)
• Desenvolvedores
• Descrição da implementação dos 
módulos e suas dependências
• Abrange o gerenciamento de versões 
do sistema, construídas pelo 
agrupamento de módulos 
(componentes) e subsistemas
Visão de implantação (física, de 
organização)
• Contém a parte física do sistema e a 
conexão entre as sub partes, interação 
entre hw-sw, com o objetivo de colocar 
o sistema em operação
Visão de processo
• Enfatiza as características de 
concorrência, sincronização e 
desempenho do sistema
Casos de uso
Levantamento de requisitos
• É a etapa de compreensão do problema aplicada ao desenvolvimento de 
software.
• O principal objetivo do levantamento de requisitos é que o usuários e 
desenvolvedores tenha a mesma visão do problema a ser resolvido
• Nessa etapa, os desenvolvedores, juntamente dos clientes, tentam levantar e 
definir as necessidades dos futuros usuários do sistema a ser 
desenvolvido(requisitos)
Requisitos funcionais
• Definem as funcionalidades do sistemas
 “o sistema deve permitir que cada professor realize o lançamento de notas das 
turmas nas quais lecionou”
 “o sistema deve permitir que um aluno realize sua matrícula nas disciplinas 
oferecidas em um semestre letivo”
 “os coordenadores de escola devem poder obter o número de aprovações, reprovações 
e trancamentos em cada disciplina oferecida em um determinado período”
Requisitos não-funcionais
• Declaram características de qualidade que o sistema deve possuir e que 
estão relacionadas às suas funcionalidades
 Confiabilidade: tempo médio entre falhas, recuperação de falhas
 Desempenho: tempos de resposta esperados
 Portabilidade: restrições as plataformas de hw
 Segurança: restrições do sistema em relação a acessos não-autorizados
 Usabilidade: facilidadede uso, necessidade ou não de treinamento dos usuários
Requisitos normativos
• Declaração de restrições impostas sobre o desenvolvimento do sistema como 
adequação a prazos, custos, plataforma tecnológica, aspectos legais, regras 
de negócio, políticas de funcionamento específicas do domínio do problema
Análise
• Corresponde a quebrar o sistema em seus componentes e estudar como tais 
componentes interagem com o objetivo de entender como esse sistema 
funciona
• Os modelos construídos na fase de análise devem ser cuidadosamente 
validados e verificados, através da validação e verificação dos modelos, 
respectivamente
Modelagem de casos de uso
• Representação das funcionalidades externamente observáveis do sistema e 
dos elementos externos ao sistema que interagem entre eles(Bezerra, 2007. 
pág. 53)
• O modelo de caso de uso é importante, pois direciona diversas tarefas 
posteriores do processo de desenvolvimento de um sistema de software. 
• Esse modelo força os desenvolvedores a modelar o sistema de 
acordo com as necessidades do usuário
•Esse modelo representa os requisitos funcionais do sistema.
•Também direciona diversas das atividades posteriores do ciclo de vida do sistema de
software.
Casos de uso
• Um caso de uso, é a especificação de uma sequência completa de interações 
entre um sistema e um ou mais agentes externos a esse sistema
• Um caso de uso representa uma determinada funcionalidade de um sistema 
conforme percebida externamente. Representa também os agentes externos 
que interagem com o sistema.
• *** um caso de uso não revela a estrutura e os comportamento interno do 
sistema
• Cada caso de uso se define pela descrição narrativa (textual) das interações 
que ocorrem entre os elementos externos e o sistema
• A UML não define a estrutura textual a ser utilizada na descrição de um 
caso de uso (Bezerra, 2007. Pág. 55)
Utilidade dos Casos de Uso
• Equipe de clientes (validação)
– aprovam o que o sistema deverá fazer
– entendem o que o sistema deverá fazer
Equipe de desenvolvedores•
–
–
–
–
Ponto de partida para refinar requisitos de software.
Podem seguir um desenvolvimento dirigido a casos de uso. 
Designer (projetista): encontrar classes
Testadores: usam como base para casos de teste
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição