ANÁLISE ORIENTADA A OBJETOS
Ago/2010
Professor Mário Dantas
Ementa da Disciplina
1.
A UML - Linguagem de Modelagem Unificada
 História
 Métodos
que originaram a UML
 Elementos
 Aplicação
 Processos
 Ferramentas de Apoio
2.
Engenharia de Requisitos

Definição e Etapas
Ementa da Disciplina
3.
Diagramas:
 Caso
de Uso: Aplicação e Notação
 Atividade: Aplicação e Notação
 Classes: Aplicação e Notação
 Objeto: Uso, Notação
 Interação - Seqüência: Aplicação e Notação
 Interação – Interação Geral
 Estrutura Composta: Uso, Notação e Aplicação
 Estados: Uso, Notação e Aplicação
 Demais Diagramas da UML 2.0 e extensões: Uso,
Notação
Bibliografia Básica



WAZLAWICK, Raul Sidnei. Análise e Projeto de
Sistemas de Informação Orientados a Objetos,
Campus, 2004.
RUMBAUGH, James e BLAHA, Michael. Modelagem
e projetos baseados em objetos com UML 2.
Campus, 2006.
MEDEIROS, Ernani. Desenvolvendo Software com
UML 2.0 Definitivo. Makron Books, 2004.
Bibliografia Complementar




TAFNER, Malcon A. & Carlos Henrique Correia.
Análise Orientada a Objetos. 2 Ed., Visual Books,
2006.
MELO, Ana Cristina. Exercitando Modelagem em
UML. Brasport, 2006.
BEZERRA, Eduardo. Princípio de Análise e Projetos
de Sistemas com UML. Elsevier - Campus, 2006.
PENDER, Tom. UML: a Bíblia. 1 ed., Campus, 2004.
Aula 01 - Agenda



Grandes Verdades Sobre Software
Conceitos Fundamentais
A UML - Linguagem de Modelagem Unificada
 História
 Métodos
que originaram a UML
 Elementos
Histórico

Anos 60 – 70
 COBOL,
FORTRAN E C
 Métodos de Análise e Projeto Estruturado

Final dos anos 60
 Simula
(primeira linguagem a incorporar elementos de
OO)

Anos 80 e início dos anos 90
 ADA,
Smalltalk e C++
 Primeiros métodos de OO
Histórico

Restante dos anos 90: início da atração por OO
 Java,
UML e Unified Process
 Proliferação de métodos OO
 Método:
notação + atividades
Métodos OO Precursores

1989 – Wirfs-Brock
 Cartões
CRC ( Classe – Responsabilidade –
Colaborador)

1991 – Coad / Yourdon
 OOA

e OOD
1991 – Grady Booch
 Método

BOOCH
1991 – James Rumbaugh
 Método
OMT (Object Modeling Technique)
Métodos OO Precursores

1992 – Ivar Jacobson
 OBJECTORY

OOSE
1994 – Coleman
 Método
Fusion (Mistura de conceitos presentes nos
métodos Booch, OMT, CRC e Métodos Formais).
Antes da UML


Vários métodos surgem entre 89 e 94 (“Guerra dos
métodos”)
Novas versões dos métodos, incorporando técnicas
uns dos outros (OOSE, OMT-2, Booch’93)
 Reconhecia-se
que havia pontos mais fortes em cada
um dos métodos

Parceria entre Booch e Rumbaugh (Rational) –1994
 Unified
Method (UM)
Antes da UML

Rational a incorpora a Objective Systems
(Objectory) de Jacobson – 1995
 Parceria
Booch/Rumbaugh estendida com Jacobson
 Unified Modeling Language (UML)
Surgimento da UML
BOOCH
UML
 Diagrama de Estados
 Diagrama de Objetos
(Colaboração)
 Diagrama de Processo
(Desenvolvimento)
 Diagrama de Módulos
(Componentes)
OMT
 Diagrama de Estados
 Diagrama de Classes
OOSE




Use Case
Subsistemas (Package)
Diagrama de Interações
MiniEspecificação
Surgimento da UML
Mais Contribuições
UML

A UML - Unified Modeling Language é uma
linguagem para especificação, documentação,
visualização e desenvolvimento de sistemas
orientados a objetos. Por meio de seus diagramas é
possível representar sistemas de softwares sob
diversas perspectivas de visualização.
UML

A UML é uma linguagem de modelagem não
proprietária de terceira geração. A UML não é
uma metodologia de desenvolvimento, o que
significa que ela não diz para você o que fazer
primeiro e em seguida ou como projetar seu
sistema, mas ela lhe auxilia a visualizar seu
desenho e a comunicação entre objetos.
A modelagem visual com UML





Permite a compreensão de detalhes de sistemas
complexos;
Melhora a comunicação entre a equipe de projeto;
Fornece base não ambígua para a implementação;
Permite a formulação de alternativas de solução e
sua comparação a baixo custo;
Captura os requisitos de modo preciso.
A Estrutura de Conceitos do UML
“Elementos”
Relações (relacionam “elementos”)
Diagramas (agrupam “elementos”)
A EC do UML: Elementos

Elementos de Estrutura

Elementos de Comportamento

Elementos de Agrupamento

Elementos de Anotação
A EC do UML: Elementos
Elementos de Estrutura
A EC do UML: Elementos
A EC do UML: Relações
Tipos de Relações
A EC do UML: Diagramas
Visão Funcional
 Diagrama de casos de utilização
 Diagrama de atividade
Visão Dinâmica
 Diagrama de máquina de
estados (state machine diagram)
 Diagrama de interação




Diagrama de sequência
Diagrama de comunicação
Diagrama de visão geral da
interação (interaction overview
diagram)
Diagrama temporal (timing
diagram)
Visão Estática ou Estrutural

Diagrama de pacotes

Diagrama de classes

Diagrama de objetos

Diagrama de estrutura
composta (composite structure
diagram)

Diagrama de componentes

Diagrama de instalação
A EC do UML: Exemplos
Diagrama de Casos de Utilização: representa a visão do sistema na
perspectiva dos seus utilizadores
(e.g., UAnónimo no contexto do WebGTTI)
A EC do UML: Exemplos
Diagrama de Classes: especifica a estrutura estática de um sistema segundo a
abordagem baseada em objectos (e.g., classes do WebGTTI)
A EC do UML: Exemplos
Diagrama de Sequências:
especifica a dinâmica ou o
comportamento de um
sistema
(e.g., registo de membro
no WebGTTI)
A EC do UML: Exemplos
Exemplo de um
Diagrama de Atividades
(processo de negócio
“Fazer Proposta”)
A EC do UML: Exemplos
Diagrama de Distribuição
(e.g., arquitectura hardware de um sistema distribuído)
A EC do UML: Exemplos
Diagrama de (Transição de) Estados
(e.g., da classe “Termo” do WebGTTI)
Aplicação

A UML é uma linguagem para:
 Visualização
 Especificação
 Construção
 Documentação

A UML fornece um método padrão para descrever
um sistema tendo em conta aspectos conceituais
e/ou concretos.
Visualização



Modelos explícitos facilitam a comunicação
Algumas estruturas transcendem o que pode ser
representado por uma linguagem de programação
Cada símbolo tem uma semântica bem definida.
Especificação

A notação UML permite a especificação das
decisões importantes em nível de análise, projeto,
implementação e implantação
Construção

Forward engineering
 Geração

Background engineering
 Geração

de código com base no modelo
do modelo com base no código
Round-Trip engineering
 Ciclo
iterativo de desenvolvimento com geração de
código a parir de um modelo e atualização do modelo
com base no código.
Documentação

A notação UML permite a criação de
documentação do artefatos existentes no sistema:
 Conceitos
do problema
 Cenários de instalação

É possível acrescentar links para documentação
externa:
 Documentos
de requisitos, planos de testes, ...
Razões para modelar




Comunicar a estrutura e o comportamento desejado
(desejável) para o sistema
Visualizar e controlar a arquitetura do sistema
Compreender o sistema e expor oportunidade de
simplificação e reutilização
...
Triângulo para o sucesso

Este conceito pertence a Terry Quatrani, autora do
livro: Modelagem Visual com Rational Rose 2000 e
UML.
Notação
Processo
Ferramenta
Triângulo para o sucesso




Segundo Terry, para um projeto bem sucedido é
necessário conhecer bem três coisas: Notação,
Processo e Ferramenta.
Você pode saber uma notação, mas se não souber
usar (Processar), terá falha;
Você pode ter um ótimo processo, mas se não
souber comunicar (Notação), terá falha
Se não souber documentar seu trabalho
(Ferramenta), terá falha.
Processo de Desenvolvimento

O que é um processo de desenvolvimento?



É a definição de quem faz o que, quando e como, para atingir
um certo alvo.
UML é uma linguagem de modelagem, não é uma
metodologia. Não se consegue fazer uma boa
modelagem sem conhecer processos.
Linguagem de modelagem + processo de
desenvolvimento = método (ou metodologia) de
desenvolvimento.
Processo de Desenvolvimento

As grandes fases de qualquer processo de
desenvolvimento são:
 Planejamento
e elaboração
 Planejamento,
definição de requisitos, construção de
protótipos (opcional)
 Construção
do sistema (inclui codificação e testes)
 Implantação (colocar em produção, treinar usuários, ...)
Processo de Desenvolvimento


UML não depende de processo. Você deve escolher
o que for adequado ao seu projeto.
Existem diversos modelos, e esse modelos são
influenciados por alguns fatores como:
 Tipo
de software que será desenvolvido (real-time,
sistema de informação, etc.)
 Escala (Um desenvolvedor, equipe pequena, etc.)
Processo em cascata
Processo Unificado


O processo unificado (PU) de desenvolvimento de
software é o conjunto de atividades necessárias
para transformar requisitos do usuário em um
sistema de software.
É fundamental na visão de que o avanço de um
projeto deve estar baseado na construção de
artefatos de software, e não apenas em
documentação.
Processo Unificado

Principais Características:
 Dirigido
por casos de uso.
 Descrições
de casos de uso e seus diagramas embasam a
construção do software.
 Centrado
na arquitetura.
O
documento visão, diagrama de componentes e
implantação, diagrama de interação e diagrama de classes
(modelo de dados) fornecem a perspectivas da arquitetura
do software.
 Interativo
e incremental.
Fases do Processo Unificado
• Visão do Software
• Tecnologia
• Riscos
• Áreas críticas
Concepção
Elaboração
• Requisitos em
detalhes
• Protótipos
• Codificação
• Banco de Dados
Construção
Transição
• Avaliação do
software
• Versão de
Produção
Workflows do PU
Requisitos
Testes
Implementação
Análise
Projeto
Processo Unificado
Ferramentas



O que são Ferramentas CASE?
A sigla CASE significa “Computer-Aided Software
Engineering”.
Traduzindo para um bom português: “Engenharia
de Software Auxiliada por Computador”.
Ferramentas

1.
2.
3.
As ferramentas se dividem em três categorias. São
elas:
Lower CASE - ferramentas de codificação (frontend);
Upper CASE - ferramentas de análise, projeto e
implementação;
Integrated CASE - união de Upper e Lower CASE.
Ferramentas



Como escolher a ferramenta?
O primeiro passo é saber qual será o uso da
ferramenta na sua empresa. Isto é, ferramenta
para codificação ou ferramenta para análise.
Outro fator importante é que a ferramenta deve
ser aderente ao conceitos de trabalho na sua
empresa.Como estes conceitos e técnicas evoluem
no tempo.
Ferramentas

Questões importantes para escolha da ferramenta:
1.
2.
3.
O time de desenvolvimento está preparado
tecnicamente para trabalhar com ferramentas case?
Preciso capacitar os recursos de minha empresa?
A metodologia de desenvolvimento em minha
empresa está “amadurecida”?
Ferramentas

Na prática, as ferramentas existentes no mercado
possuem as características das quais destacam-se os
seguintes pontos:
Desenvolvidas sobre uma arquitetura inteligente
(customizável);
 Possuem "facilitadores" para auxiliar nas tarefas
repetitivas;
 Verificação da consistência através de regras específicas;
 Geração de relatórios para acompanhamento do trabalho;
 Interfaces com outros aplicativos de desenvolvimento.

Ferramentas
“Uma ferramenta CASE não é a solução para todos
os problemas da organização. A organização deve
ter certeza de estar pronta para a nova ferramenta.
Desta forma uma ferramenta só deveria ser
selecionada após a definição do processo de
desenvolvimento, dos métodos e de ter sido utilizada
num projeto piloto.” (Reid).
Ferramentas

Comerciais e “Free Editions”
 MagicDraw
($ 1,599,00)
 Together Architect ( $ 11.500,00)
 Poseidon ($ 875,00 )
 Enterprise Architect ($ 2.500,00)
 Rose Technical Developer ($6,880.00)
 Jude/Astah ($280,00 1usuário/1ano)
 Omondo Eclipse UML ($ 84,900.00 / 20 usuários)
 Visual Paradigm ($ 699)
Fonte: http://www.objectsbydesign.com/tools/umltools_byPrice.html
Ferramentas

Livres (BSD e GPL)
 Umbrello
 ArgoUML
 Dia
 BOUML
 Fajuba
 StarUML



Dia é um programa baseado em gtk+ para criação
do diagrama, liberado sob a licença GPL.
É parte do projeto Gnome.
Atualmente tem objetos especiais de lógica,
entidade e relacionamento, diagramas UML,
fluxogramas, diagramas da rede, e circuitos simples
entre outros.
ArgoUML



ArgoUML é uma ferramenta CASE baseada na
notação UML (Unified Modeling Language).
Foi
desenvolvido
pela
comunidade
de
desenvolvedores de código livre Tigris vinculada a
Universidade da California, Berkeley.
Sua interface é bem completa o que a torna um
pouco complexa de manipular.


Umbrello e um Software de Modelagem UML, que
e integrado ao projeto KDE.
Este Software é utilizado para modelar o próprio
projeto do KDE por a grande de seus
desenvolvedores que utilizam UML.



JUDE é uma ferramenta profissional de modelagem
para sistemas a qual suporta UML, diagrama entidade
relacionamento, Flowchart, CRUD, Mini Mapas e
Diagrama de Fluxo de Dados.
Permite também a conversão entre modelos UML, ER
Diagramas, Flowcharts, fluxo de dados e mini mapas.
O nome do programa é um acrônimo de Java and UML
Developers
Environment
(Ambiente
para
Desenvolvedores UML e Java).