5.256 visualizações

Publicada em


Publicada em: Tecnologia, Educação
0 comentários
3 gostaram
  • Seja o primeiro a comentar

Sem downloads
Visualizações totais
No SlideShare
A partir de incorporações
Número de incorporações
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • Large enterprise applications - the ones that execute core business applications, and keep a company going - must be more than just a bunch of code modules. They must be structured in a way that enables scalability, security, and robust execution under stressful conditions, and their structure - frequently referred to as their architecture - must be defined clearly enough that maintenance programmers can (quickly!) find and fix a bug that shows up long after the original authors have moved on to other projects. That is, these programs must be designed to work perfectly in many areas, and business functionality is not the only one (although it certainly is the essential core). Of course a well-designed architecture benefits any program, and not just the largest ones as we've singled out here. We mentioned large applications first because structure is a way of dealing with complexity, so the benefits of structure (and of modeling and design, as we'll demonstrate) compound as application size grows large. Another benefit of structure is that it enables code reuse : Design time is the easiest time to structure an application as a collection of self-contained modules or components. Eventually, enterprises build up a library of models of components, each one representing an implementation stored in a library of code modules. When another application needs the same functionality, the designer can quickly import its module from the library. At coding time, the developer can just as quickly import the code module into the application.  
  • Não é possível avaliar tudo isso na implementação. O momento ideal é no projeto do software.
  • Modeling is the designing of software applications before coding. Modeling is an Essential Part of large software projects, and helpful to medium and even small projects as well. A model plays the analogous role in software development that blueprints and other plans (site maps, elevations, physical models) play in the building of a skyscraper. Using a model, those responsible for a software development project's success can assure themselves that business functionality is complete and correct, end-user needs are met, and program design supports requirements for scalability, robustness, security, extendibility, and other characteristics, before implementation in code renders changes difficult and expensive to make. Surveys show that large software projects have a huge probability of failure - in fact, it's more likely that a large software application will fail to meet all of its requirements on time and on budget than that it will succeed. If you're running one of these projects, you need to do all you can to increase the odds for success, and modeling is the only way to visualize your design and check it against requirements before your crew starts to code.
  • Modelos ajuda a pessoas iniciantes a se interarem do projeto mais rapidamente; Melhor errar no modelo; Modelar reduz a necessidade de retrabalho;
  • Cada notação gráfica possuía suas vantagens e desvantagens;
  • Ver versão; Em aperfeiçoamento questões como programação concorrente, etc.
  • The OMG's Unified Modeling Language™ ( UML® ) helps you specify, visualize, and document models of software systems, including their structure and design, in a way that meets all of these requirements. (You can use UML for business modeling and modeling of other non-software systems too.) Using any one of the large number of UML-based tools on the market , you can analyze your future application's requirements and design a solution that meets them, representing the results using UML 2.0's thirteen standard diagram types .  You can model just about any type of application, running on any type and combination of hardware, operating system, programming language, and network, in UML. Its flexibility lets you model distributed applications that use just about any middleware on the market. Built upon  fundamental OO concepts including class and operation , it's a natural fit for object-oriented languages and environments such as C++, Java, and the recent C#, but you can use it to model non-OO applications as well in, for example, Fortran, VB, or COBOL.  UML Profiles (that is, subsets of UML tailored for specific purposes) help you model Transactional, Real-time, and Fault-Tolerant systems in a natural way.  You can do other useful things with UML too: For example, some tools analyze existing source code (or, some claim, object code!) and reverse-engineer it into a set of UML diagrams. Another example: Some tools on the market execute UML models, typically in one of two ways: Some tools execute your model interpretively in a way that lets you confirm that it really does what you want, but without the scalability and speed that you'll need in your deployed application. Other tools (typically designed to work only within a restricted application domain such as telecommunications or finance) generate program language code from UML, producing most of a bug-free, deployable application that runs quickly if the code generator incorporates best-practice scalable patterns for, e.g., transactional database operations or other common program tasks. (OMG members are working on a specification for Executable UML now.) Our final entry in this category: A number of tools on the market generate Test and Verification Suites from UML models. 
  • What can you Model with UML? UML 2.0 defines thirteen types of diagrams, divided into three categories: Six diagram types represent static application structure; three represent general types of behavior; and four represent different aspects of interactions: Structure Diagrams include the Class Diagram, Object Diagram, Component Diagram, Composite Structure Diagram, Package Diagram, and Deployment Diagram.  Behavior Diagrams include the Use Case Diagram (used by some methodologies during requirements gathering); Activity Diagram, and State Machine Diagram.  Interaction Diagrams, all derived from the more general Behavior Diagram, include the Sequence Diagram, Communication Diagram, Timing Diagram, and Interaction Overview Diagram.
  • Documenta as funcionalidades básicas do sistema, do ponto de vista do usuário; Ajudam a compreender os requisitos; Guiam o desenvolvimento do sistema, e muitas vezes são utilizados para dividir o desenvolvimento de sistemas em tarefas; Muitas vezes os requisitos levantados juntamente com os clientes são mapeados em use cases.
  • Além de pessoas, também sistemas externos são representados por atores. Por exemplo, se você estiver desenvolvendo um sistema de automação para uma máquina da produção, que irá trocar informações com o sistema de estoque da indústria, este é representado nos diagramas por um ator.
  • Relaciona classes que precisam conhecer uma a outra para realizar o seu trabalho;
  • Relaciona classes que precisam conhecer uma a outra para realizar o seu trabalho;
  • Relaciona classes que precisam conhecer uma a outra para realizar o seu trabalho;
  • Relaciona classes que precisam conhecer uma a outra para realizar o seu trabalho;
  • Relaciona classes que precisam conhecer uma a outra para realizar o seu trabalho;
  • Relaciona classes que precisam conhecer uma a outra para realizar o seu trabalho;
  • Relaciona classes que precisam conhecer uma a outra para realizar o seu trabalho;
  • Relaciona classes que precisam conhecer uma a outra para realizar o seu trabalho;
  • Certos projetos permitem automatismos sobre os modelos, de maneira a gerar código ou base de dados;
  • 2) Select a UML Development Tool: Because most (although not all) UML-based tools implement a particular methodology, in some cases it might not be practical to pick a tool and then try to use it with a methodology that it wasn't built for. (For other tool/methodology combinations, this might not be an issue, or might be easy to work around.) But, some methodologies have been implemented on multiple tools so this is not strictly a one-choice environment.  You may find a tool so well-suited to your application or organization that you're willing to switch methodologies in order to use it. If that's the case, go ahead - our advice to pick a methodology first is general, and may not apply to a specific project. Another possibility: You may find a methodology that you like, which isn't implemented in a tool that fits your project size, or your budget, so you have to switch. If either of these cases happens to you, try to pick an alternative methodology that doesn't differ too much from the one you preferred originally.  As with methodologies, OMG doesn't have an opinion or rating of UML-based modeling tools, but we do have links to a number of lists here . These will help you get started making your choice. 
  • Uml

    1. 1. Unified Modeling Language Maurício Edgar Stivanello
    2. 2. Agenda <ul><li>Software e modelagem; </li></ul><ul><li>UML </li></ul><ul><ul><li>Introdução; </li></ul></ul><ul><ul><li>Diagramas; </li></ul></ul><ul><li>Comentários finais; </li></ul>
    3. 3. Agenda <ul><li>Software e modelagem; </li></ul><ul><li>UML </li></ul><ul><ul><li>Introdução; </li></ul></ul><ul><ul><li>Diagramas; </li></ul></ul><ul><li>Comentários finais; </li></ul>
    4. 4. Evolução do software <ul><li>O surgimento de sistemas de software complexos resultou na necessidade de reavaliar a forma de desenvolver sistemas; </li></ul><ul><li>As técnicas tem evoluído de forma impressionante, notavelmente no que tange à modelagem de sistemas. </li></ul>
    5. 5. Novos requisitos de sistemas <ul><li>Escalabilidade; </li></ul><ul><li>Segurança; </li></ul><ul><li>Robustez; </li></ul><ul><li>De fácil manutenção; </li></ul><ul><li>Reutilizável; </li></ul><ul><li>Como resolver isso... </li></ul>
    6. 6. Modelagem <ul><li>Um modelo pode ser visto como uma representação idealizada de um sistema a ser construído; </li></ul><ul><li>Maquetes de edifícios e de aviões e plantas de circuitos eletrônicos são apenas alguns exemplos de modelos; </li></ul><ul><li>Uma simplificação da realidade que nos ajuda a entender um problema complexo; </li></ul>
    7. 7. Modelagem de software <ul><li>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 diversas perspectivas diferentes e complementares. </li></ul>
    8. 8. Para que modelar <ul><li>Ajuda no gerenciamento da complexidade inerente ao desenvolvimento de software; </li></ul><ul><li>Ajuda na comunicação entre as pessoas envolvidas; </li></ul><ul><li>Ajuda na predição do comportamento futuro do sistema. </li></ul>
    9. 9. Evolução da modelagem <ul><li>Na primeira metade da década de 90 surgiram várias propostas de técnicas para modelagem de sistemas; </li></ul><ul><li>Houve uma grande proliferação de propostas para modelagem de sistemas segundo o paradigma orientado a objetos; </li></ul><ul><li>Existiam diferentes notações gráficas para modelar uma mesma perspectiva de um sistema. </li></ul>
    10. 10. Necessidade de um padrão <ul><li>Percebeu-se a necessidade de um padrão para a modelagem de sistemas, que fosse aceito e utilizado amplamente; </li></ul><ul><li>Surgiram esforços nesse sentido de padronização, sendo o principal liderado por James Rumbaugh, Grady Booch e Ivar Jacobson (Rational). </li></ul>
    11. 11. Agenda <ul><li>Software e modelagem; </li></ul><ul><li>UML </li></ul><ul><ul><li>Introdução ; </li></ul></ul><ul><ul><li>Diagramas; </li></ul></ul><ul><li>Comentários finais; </li></ul>
    12. 12. UML... <ul><li>Surge a UML em 1996 como a melhor candidata para ser a linguagem unificadora de notações; </li></ul><ul><li>Em 1997 a UML é aprovada como padrão pela OMG; </li></ul><ul><li>Desde então tem tido grande aceitação; </li></ul><ul><li>Atualmente na versão 2.0; </li></ul>
    13. 13. Características da UML <ul><li>É uma linguagem visual; </li></ul><ul><li>É independente de linguagem de programação; </li></ul><ul><li>É independente de processo de desenvolvimento; </li></ul><ul><li>Não é uma linguagem de programação; </li></ul><ul><li>Não é uma metodologia. </li></ul>
    14. 14. Usos da UML <ul><li>Visualização; </li></ul><ul><li>Especificação; </li></ul><ul><li>Documentação; </li></ul><ul><li>Comunicação; </li></ul><ul><li>Construção. </li></ul>
    15. 15. Diagramas Podem ser usados para... <ul><li>Mostrar os limites de um sistema e suas funções; </li></ul><ul><li>Representa a estrutura estática de um sistema; </li></ul><ul><li>Modelar o comportamento de objetos; </li></ul><ul><li>Apresentar a implementação física e a arquitetura de um sistema; </li></ul>
    16. 16. Elementos Essenciais Estruturais Classe Objeto Interface Nó Componente Relacionamentos
    17. 17. Elementos Essenciais Comportamentais Caso de uso Ator Estados Mensagens
    18. 18. Elementos Essenciais Extensão Notas Tagged Values
    19. 19. Elementos Essenciais Agrupamento Pacotes
    20. 20. Agenda <ul><li>Software e modelagem; </li></ul><ul><li>UML </li></ul><ul><ul><li>Introdução; </li></ul></ul><ul><ul><li>Diagramas ; </li></ul></ul><ul><li>Comentários finais; </li></ul>
    21. 21. Diagrama de Casos de Uso Visão Geral <ul><li>Descreve o que o sistema faz do ponto de vista do observador externo; </li></ul><ul><li>Ajuda a esclarecer os requisitos do sistema; </li></ul><ul><li>Ajuda a dividir o desenvolvimento do sistema em tarefas; </li></ul>
    22. 22. Diagrama de Casos de Uso Caso de uso <ul><li>Representa as diferentes funcionalidades que o sistema disponibiliza aos usuários. </li></ul>
    23. 23. Diagramas de Caso de Uso Atores <ul><li>Diferentes usuários que operam o sistema; </li></ul><ul><li>Sistemas externos que interagem com o sistema; </li></ul>
    24. 24. Diagramas de Caso de Uso Associação <ul><li>Representa a comunicação entre o ator e o caso de uso; </li></ul><ul><li>Também existem associações entre casos de usos; </li></ul>
    25. 25. Diagramas de Caso de Uso Diagrama completo
    26. 26. Diagramas de Classe Visão Geral <ul><li>Largamente utilizado; </li></ul><ul><li>Descreve os diferentes tipos de objeto e o relacionamentos entre eles. </li></ul>
    27. 27. Diagramas de Classe Classes <ul><li>Estereótipo; </li></ul><ul><li>Atributos; </li></ul><ul><li>Operações; </li></ul><ul><li>Visibilidade; </li></ul><ul><li>Tipo; </li></ul>
    28. 28. Diagramas de Classe Relacionamentos <ul><li>Associações representam relações entre ocorrências de classes; </li></ul>
    29. 29. Diagramas de Classe Relacionamentos <ul><li>Multiplicidade; </li></ul><ul><li>Navegabilidade; </li></ul>
    30. 30. Diagramas de Classe Relacionamentos <ul><li>Agregação; </li></ul><ul><li>Composição; </li></ul>
    31. 31. Diagramas de Classe Relacionamentos <ul><li>Generalização; </li></ul><ul><li>Dependência; </li></ul>
    32. 32. Diagramas de Classe Pacotes <ul><li>Agrupa classes relacionadas; </li></ul>
    33. 33. Diagramas de Classe Diagrama completo
    34. 34. Diagrama de Seqüência <ul><li>Mostra um conjunto de objetos, seus relacionamentos e as mensagens que podem ser enviadas entre eles; </li></ul><ul><li>Diagrama de seqüência dá ênfase à seqüência de mensagens; </li></ul>
    35. 35. Diagrama de Seqüência Objetos <ul><li>Representa uma instância de uma determinada classe; </li></ul>
    36. 36. Diagrama de Seqüência Mensagens <ul><li>Representa troca de mensagens entre os objetos; </li></ul>
    37. 37. Diagrama de Seqüência Fragmentos <ul><li>Servem para separar blocos de mensagens condicionadas a teste ou laço; </li></ul>
    38. 38. Diagrama de Seqüência
    39. 39. Diagrama de estados <ul><li>Exibe os possíveis estados de um objeto; </li></ul><ul><li>Exibe também as transições que causam a mudança de estado. </li></ul>
    40. 40. Diagramas de Classe Elementos básicos <ul><li>Estado inicial; </li></ul><ul><li>Estado final; </li></ul><ul><li>Estado intermediário; </li></ul>
    41. 41. Diagramas de Estados Diagrama completo
    42. 42. Diagramas de Implantação Visão Geral <ul><li>Mostra a configuração de software ou hardware; </li></ul><ul><li>Permite avaliar as diferentes situações de implantação do sistema. </li></ul>
    43. 43. Diagramas de Implantação Elementos básicos <ul><li>Componente; </li></ul><ul><li>Nó. </li></ul>
    44. 44. Diagramas de Implantação Diagrama completo
    45. 45. Agenda <ul><li>Software e modelagem; </li></ul><ul><li>UML </li></ul><ul><ul><li>Introdução; </li></ul></ul><ul><ul><li>Diagramas; </li></ul></ul><ul><li>Comentários finais ; </li></ul>
    46. 46. Design na metodologia hoje Exemplo do RUP
    47. 47. Quanto esforço empregar <ul><li>Projeto; </li></ul><ul><li>Equipe de trabalho; </li></ul><ul><li>Complexidade; </li></ul><ul><li>Automatismos possíveis; </li></ul>
    48. 48. Engenharia Reversa <ul><li>Útil quando se quer trabalhar com sistemas sem documentação; </li></ul><ul><li>Nem sempre o resultado é satisfatório; </li></ul>
    49. 49. Ferramentas sugeridas <ul><li>StarUML em </li></ul><ul><li>Poseidon em </li></ul><ul><li>Umbrello em </li></ul><ul><li>Rational Rose em </li></ul><ul><li>Dentre outras... </li></ul>
    50. 50. Fontes <ul><li>OMG – </li></ul><ul><li>UML – </li></ul><ul><li>UML Essencial – Grady Booch, Ivar Jacobson e James Rumbaugh </li></ul>
    51. 51. Obrigado... [email_address]