Análise e Projeto de Sistemas OO
Análise e Projeto de Sistemas OO Por que fazer a modelagem?
Importância da modelagem
Linguagem padrão de modelagem adotada internacionalmente pela indústria de software
Utilização de uma notação padronizada que abrange qualquer tipo de sistema
Facilidade no entendimento da orientação a objetos Exigência de mercado
Qualidade Estimativa
Gerenciar modificações Comunicação
Conceito em realidade
168
Muitas empresas de desenvolvimento de software começam querendo construir prédios altos, como se estivessem fazendo uma casinha de cachorro (Booch, et al).
Problema
169
Modelagem no mercado de trabalho
Indústria de construção Construções de aviões Dispositivos elétricos Sistemas de telefonia Indústria cinematográfica
170
Construímos modelos de sistemas complexos porque não é possível compreendê-los em sua totalidade
Segundo Edsger Dijkstra ataque um problema difícil, dividindo-o em vários problemas menores que você possa solucionar
Edsger Dijkstra:
http://pt.wikipedia.org/wiki/Edsger_Dijkstra
Modelagem
171
Modelagem
Engenheiros Civis fazem plantas antes de construírem prédios
Engenheiros eletrônicos fazem esquemas antes de montarem aparelhos
Engenheiros Mecânicos fazem desenhos antes de produzirem máquinas
Engenheiros de Software são superdotados pela Mãe Natureza, e não precisam de nada disso
“Se prédios fossem construídos da mesma forma que fazemos sistemas, o primeiro pica pau que aparecesse no planeta destruiria a humanidade”
(autor desconhecido)
172
A engenharia de software é uma área muito nova!
O ser humano faz casas e abrigos há milhões de anos
O ser humano lida com eletricidade há milhares de anos
O ser humano produz máquinas e ferramentas há outros milhares de anos
O ser humano faz softwares há 40/50/60 anos.
Estamos nos primórdios da computação...
173
Levantamento e Análise de Requisitos
Um sistema bem modelado depende de um levantamento de requisitos de qualidade e muito bem validado
Compreender as necessidades do usuário.
O que o usuário deseja que o sistema realize.
Muitas entrevistas.
174
Levantamento e Análise de Requisitos
A questão é!!!
Como saber se as necessidades dos usuários foram realmente bem compreendidas??
Realizar quantas entrevistas forem necessárias Analisar os requisitos levantados
175
Outros Conceitos Importantes
Prototipagem Prazos e Custos Manutenção
Documentação Histórica
176
UML – Unified Modeling Language
Desenvolvida por Grady Booch, James Rumbaugh, e Ivar Jacobson que são conhecidos como "os três amigos "
A UML é a junção de três metodologias:
Booch, OMT e OOSE/Objectory
177
A Trajetória de UML
Primeira proposta de linguagem orientada a objetos:
Smalltalk (Xerox Parc) Desenvolvimento de C++
Surgiu a preocupação de criar métodos de projetos em um mundo orientado a objetos
Vários pesquisadores e grupos propuseram diferentes métodos de análise e projeto O.O.
Peter Coad e Ed Yourdon Grady Booch
Jim Rumbaugh
Ivar Jacobson 178
A Guerra dos Métodos
As diferenças de notação entre os métodos gerou problemas de comunicação
OMG (Object Management Group) tentou, sem sucesso, padronizar a notação
179
O Nascimento de UML
Em 1994, Jim Rumbaugh sai da GE e se une a Grady Booch da Rational Software, com a intenção de integrar seus métodos
Declararam a guerra dos métodos
Para a conferência OOPSLA 95, Grady e Jim preparam a primeira descrição de seu método unificado
Ivar Jacobson se une à equipe
Em 1996, eles (conhecidos como os três amigos) lançam a primeira versão de UML
180
O Nascimento de UML
A OMG decidiu padronizar os métodos
Várias organizações submeteram propostas
A Rational lançou a versão 1.0 de UML como proposta
Após algumas quedas-de-braço, a versão 1.1 de UML foi adotada como padrão
Em 1999, a versão 1.3 é tornada pública
Atualmente, versão 2.2
181UML – Unified Modeling Language
Versão Ano Principais Fatos Ocorridos.
UML 0.8 1995 Lançamento do primeiro esboço da UML.
UML 0.9 1996 Integração de Jacobson à equipe da Rational Software, e seu método OOSE à expansão do escopo da UML; formação de um consórcio de empresas, com o objetivo de apoiar a definição da UML.
UML 1.0 1997 A UML foi submetida como candidata a linguagem-padrão de modelagem à OMG (Object Management Group, uma entidade de padronização estabelecida pela indústria de software).
UML 1.1 1997 Expansão do consórcio formado por empresas para apoiar a definição da UML, e aceitação da UML pela OMG.
UML 1.2 1998 Revisões e novas padronizações UML 1.3 1998 Revisões e novas padronizações UML 1.4, 1.5 1999 Revisões e novas padronizações
UML 2.0 2000 a 2003 Várias novidades em relação as versões anteriores
UML 2.0 2005 Versão oficial adotada pelo OMG (http://www.omg.org/)
182
UML – Unified Modeling Language
A UML não é uma linguagem, mas sim uma família de linguagens gráficas para modelar e construir sistemas
Inclui modelos para diferentes fases de desenvolvimento
A UML foi pensada para o desenvolvimento de sistemas orientado a objetos, mas é independente da linguagem de programação a utilizar
Permite explorar o paradigma orientado a objetos
183
UML – Unified Modeling Language
UML não é uma metodologia
Não diz quem deve fazer o quê, quando e como
A UML possibilita a trabalhar em diferentes níveis de abstração facilitando a comunicação e a análise
184
UML – Unified Modeling Language
A UML não é um processo de desenvolvimento de software, mas pode ser utilizada em diferentes processos
A UML é suportada por ferramentas :
Rational Rose (IBM), Together (Borland), Visual Paradigm, Poseidon, Jude, Umbrela, etc....
185
O que a UML não é
Uma linguagem de programação visual e sim uma linguagem para modelagem visual
A UML não é um processo de desenvolvimento de software, mas pode e deve ser aplicado a um
186
Objetivos da UML
Auxiliar engenheiros de software a definir características do software como:
Requisitos
Comportamentos Estrutura lógica
Dinâmica dos processos Necessidades físicas Etc...
187
Propósitos da UML
A UML é uma linguagem destinada a:
Documentar Visualizar Especificar Construir
188
Documentar
Artefatos como requisições de negócios, modelo de arquitetura, código fonte, modelo de análise, protótipo e outros documentos, pode ser documentados com a UML.
189
Visualizar
No processo de desenvolvimento de sistemas, é quase impossível a visualização de toda a sua estrutura sem um modelo que o represente. Dessa forma, a UML disponibiliza símbolos gráficos para a representação de artefatos de software
190
Especificar
Especificar significa: construir modelos precisos, sem ambigüidades e completos.
A UML atende todos os requisitos de especificação dentro de um processo, desde a fase de análise até a fase de testes e implementação do sistema concluído
191
Construir
Na UML é possível realizar um mapeamento dos modelos gerados, para as linguagens de programação e até mesmo para banco de dados relacionais ou orientados a objetos
192
Diagramas da UML
Por que tantos diagramas???
Fornecer múltiplas visões do sistema a ser modelado, analisando-o e modelando-o sob diversos aspectos.
Procurar atingir a completitude da modelagem, permitindo que cada diagrama complete o outro.
193
Diagramas da UML (continuação)
Por que tantos diagramas???
Cada diagrama da UML analisa o sistema, ou parte dele, sob uma determinada ótica.
A utilização de vários diagramas permite que falhas sejam descobertas, diminuindo a
possibilidade da ocorrência de erros futuros.
194
Diagrama na UML
Um diagrama é a apresentação gráfica de um conjunto de elementos, geralmente representados como gráficos de vértice (itens) e arcos (relacionamentos) (Booch, et al).
Um diagrama constitui uma projeção de um determinado sistema.
195
Blocos de construção da UML
Itens
Itens estruturais (estáticos)
Itens comportamentais (dinâmicos) Itens de agrupamento (pacotes) Itens anotacionais (notas)
Relacionamentos
Dependência Associação Generalização Realização
Diagramas
Os 13 diagramas (serão vistos mais a frente) 196
Itens
Os itens são blocos de construção da modelagem orientada a objetos. Existem quatro tipos de itens na UML. São eles:
Itens estruturais (estáticos): representam a estrutura do modelo, elementos conceituais e físicos (classes, colaborações, caso de uso, etc.)
Itens comportamentais (dinâmicos): definem o comportamento do modelo (interações e estados dos objetos)
197
Itens (continuação)
Itens de agrupamento (pacotes): são partes organizacionais da UML.
Itens anotacionais (notas): são as partes explicativas da modelo na UML (comentário e observações de esclarecimentos no modelo
198
Itens estruturais (estáticos)
São partes estáticas do modelo, representando elementos conceituais ou físicos.
Ex:
- co d ig o- na tur ez aO p era ca o - co ndic aoP a g am en to - tip oP res tSe rv ico - data E m is sa o - va lor + R eg is tr ar( ) + R ecu per ar () + C anc elar ()
N o ta F is cal
Visua l Pa ra digm fo r U M L S tan da rd Edition
classe
Cadastrar Cliente
Visual Paradigm for UML Standard E
Caso de uso
199
Itens Comportamentais (dinâmicos)
Os itens dinâmicos representam as partes de um sistema que possam ter alguma alteração.
Ex:
Mensagem
d o / V erS a ld o ()V e rific a n d o S a ld o
V is ua l P a ra di gm fo r U M L S tan da rd E ditio n( Un iv er s id ad e
200
Itens de Agrupamento (Pacotes)
Partes organizacionais dos modelos da UML. São blocos em que os modelos podem ser decompostos.
Ex:
201
Itens Anotacionais (Notas)
São partes explicativas dos modelos. São comentários, incluídos pra descrever, esclarecer e fazer alguma observação sobre qualquer elemento do modelo.
Ex:
Ultima Versão: 2.0
Visual Paradigm for UM L S tan
202
Diagramas da UML 2.0
1. Diagrama de Caso de Uso
2. Diagrama de Classe
3. Diagrama de Objetos
4. Diagrama de Estrutura Composta
5. Diagrama de Seqüência
6. Diagrama de Colaborações (Comunicação na UML 2.0)
7. Diagrama de Gráfico de Estados (Máquina de Estados na UML 2.0)
8. Diagrama de atividades
9. Diagrama de componentes
10. Diagrama de implantação
11. Diagrama de Pacotes
12. Diagrama de Interação Geral
13. Diagrama de Tempo
UML 2.0
203
Síntese Geral dos Diagramas – UML 2.0
Diagrama
Diagrama Estrutural (estáticos) Diagrama Comportamental (dinâmicos)
Diagrama de Classes
Diagrama de Objetos
Diagrama de Implantação
Diagrama de Caso de Uso
Diagrama de Atividades
Diagrama de Máquina de Estados
Diagrama de Estrutura Composta
Diagrama de Componentes
Diagrama de
Pacotes Diagrama de Interação
Diagrama de Seqüência
Diagrama Interação Geral
Diagrama de Comunicação
Diagrama de Tempo
204
Ferramentas Case
Poseidon - existe um versão opensource (Community version)
Pacestar UML - Uma versão shareware de uma ferramenta mais simples.
Rational Rose - Cópia demo do (Rational Rose Limited Edition).(10 MB)
Dia - http://dia-installer.de/shapes/UML/index.html.en ArgoUML - https://argouml.br.uptodown.com/windows Astah UML- http://astah.net/download
Star UML - http://staruml.io/
Visual Paradigm - https://www.visual-paradigm.com/
UML: Uma Visão Geral
As técnicas de UML foram projetadas para ajudar as pessoas a utilizarem a metodologia orientada a objetos
Ferramentas
Diagramas de Casos de Uso ( ) Casos de Uso
Diagramas de Classes Diagramas de Interação Diagrama de Estado Diagramas de Atividades
206
Modelagem com a UML
1.
O que fazem e desejam os usuários do sistema?(análise de processos e casos de uso).
2.
Quais são os objetos no mundo real que interagem com o sistema em estudo e suas associações?(diagrama de classes e MER).
