Professor Mário Dantas

Apresentação em tema: "Professor Mário Dantas"— Transcrição da apresentação:

1 Professor Mário Dantas
Análise Orientada a Objetos Ago/2010 Professor Mário Dantas

2 Ementa da Disciplina A UML - Linguagem de Modelagem Unificada
História Métodos que originaram a UML Elementos Aplicação Processos Ferramentas de Apoio Engenharia de Requisitos Definição e Etapas

3 Ementa da Disciplina 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

4 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.

5 Bibliografia Complementar
TAFNER, Malcon A. & Carlos Henrique Correia. Análise Orientada a Objetos. 2 Ed., Visual Books, 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.

6 Aula 01 - Agenda Grandes Verdades Sobre Software
Conceitos Fundamentais A UML - Linguagem de Modelagem Unificada História Métodos que originaram a UML Elementos

7 Histórico Anos 60 – 70 Final dos anos 60 Anos 80 e início dos anos 90
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

8 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

9 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)

10 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).

11 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)

12 Antes da UML Rational a incorpora a Objective Systems (Objectory) de Jacobson – 1995 Parceria Booch/Rumbaugh estendida com Jacobson Unified Modeling Language (UML)

13 Surgimento da UML UML BOOCH OMT OOSE Diagrama de Estados
Diagrama de Objetos (Colaboração) Diagrama de Processo (Desenvolvimento) Diagrama de Módulos (Componentes) Diagrama de Estados Diagrama de Classes Use Case Subsistemas (Package) Diagrama de Interações MiniEspecificação OOSE

14 Surgimento da UML

15 Mais Contribuições

16 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.

17 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.

18 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.

19 A Estrutura de Conceitos do UML
“Elementos” Relações (relacionam “elementos”) Diagramas (agrupam “elementos”)

20 A EC do UML: Elementos Elementos de Estrutura
Elementos de Comportamento Elementos de Agrupamento Elementos de Anotação

21 A EC do UML: Elementos Elementos de Estrutura

22 A EC do UML: Elementos

23 A EC do UML: Relações Tipos de Relações

24 A EC do UML: Diagramas Visão Estática ou Estrutural
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

25 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)

26 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)

27 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)

28 A EC do UML: Exemplos Exemplo de um Diagrama de Atividades
(processo de negócio “Fazer Proposta”)

29 A EC do UML: Exemplos Diagrama de Distribuição
(e.g., arquitectura hardware de um sistema distribuído)

30 A EC do UML: Exemplos Diagrama de (Transição de) Estados
(e.g., da classe “Termo” do WebGTTI)

31 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.

32 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.

33 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

34 Construção Forward engineering Background engineering
Geração de código com base no modelo Background engineering Geração 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.

35 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, ...

36 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 ...

37 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

38 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.

39 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.

40 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, ...)

41 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.)

42 Processo em cascata

43 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.

44 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.

45 Fases do Processo Unificado
Visão do Software Tecnologia Riscos Áreas críticas Concepção Requisitos em detalhes Elaboração Protótipos Codificação Banco de Dados Construção Avaliação do software Versão de Produção Transição

46 Workflows do PU Requisitos Análise Projeto Implementação Testes

47 Processo Unificado

48 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”.

49 Ferramentas As ferramentas se dividem em três categorias. São elas:
Lower CASE - ferramentas de codificação (front- end); Upper CASE - ferramentas de análise, projeto e implementação; Integrated CASE - união de Upper e Lower CASE.

50 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.

51 Ferramentas Questões importantes para escolha da ferramenta:
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”?

52 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.

53 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).

54 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:

55 Ferramentas Livres (BSD e GPL) Umbrello ArgoUML Dia BOUML Fajuba
StarUML

56 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.

57 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.

58 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.

59 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).