DOCSLIB.ORG

Engenharia De Software I

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Engenharia De Software I FCT-UNESP 04/07/2017 Engenharia de Software I Bacharelado em Ciência da Rogério Eduardo Garcia Computação ([email protected]) 19/04/2016 Aula 05 Material preparado por Fernanda Madeiral Delfim BCC Tópicos – Aula 5 19/04/2016 Contextualização UML Astah Diagramas no Astah 04/07/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 2 Prof. Dr. Rogério E. Garcia 1 FCT-UNESP 04/07/2017 BCC Análise Vs. Projeto 19/04/2016 04/07/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 3 BCC A/POO 19/04/2016 Como as responsabilidades devem ser atribuídas a classes de objetos? Como os objetos devem interagir? Quais classes devem fazer o quê? [Larman, 2004] 04/07/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 4 Prof. Dr. Rogério E. Garcia 2 FCT-UNESP 04/07/2017 BCC A/POO 19/04/2016 Soluções consagradas para os problemas de projeto podem ser (e têm sido) expressas na forma de princípios, heurísticas ou padrões [Larman, 2004] 04/07/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 5 BCC A/POO 19/04/2016 Análise OO: enfatiza na descoberta e descrição dos objetos (conceitos) no domínio do problema Projeto OO: enfatiza na definição dos objetos de software e como eles colaboram para a satisfação dos requisitos Implementação OO: os objetos de projeto são implementados [Larman, 2004] 04/07/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 6 Prof. Dr. Rogério E. Garcia 3 FCT-UNESP 04/07/2017 BCC Exemplo Biblioteca 19/04/2016 Livro Visualização titulo de conceito de Conceito do domínio domínio print() public class Livro { Representação private String titulo; em uma linguagem public Capitulo print() de programação OO { } } [Larman, 2004] 04/07/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 7 7 BCC 19/04/2016 04/07/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 8 Prof. Dr. Rogério E. Garcia 4 FCT-UNESP 04/07/2017 BCC UML 19/04/2016 UML (Unified Modeling Language) é uma família de notações gráficas¹, apoiada por um metamodelo² único, que ajuda na descrição e no projeto de sistemas de software ¹É a sintaxe gráfica da linguagem de modelagem ²Descreve a semântica dos elementos de modelagem 04/07/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 9 BCC UML 19/04/2016 UML nasceu da unificação das muitas linguagens gráficas de modelagem OO (final de 1980, início de 1990) UML é uma linguagem visual para especificar, construir e documentar os artefatos de software (OMG) 04/07/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 10 Prof. Dr. Rogério E. Garcia 5 FCT-UNESP 04/07/2017 BCC UML – Aplicação 19/04/2016 UML como rascunho Diagramas incompletos e informais criados para explorar partes difíceis do problema ou espaço de soluções UML como planta de software Diagramas detalhados usados para: Engenharia reversa: para visualizar e melhor entender o código existente em diagramas UML Geração de código: engenharia avante 04/07/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 11 BCC UML – Aplicação 19/04/2016 UML como linguagem de programação Especificação executável completa de um sistema de software Código executável será automaticamente gerado Ainda em desenvolvimento em termos de teoria, ferramentas robustas e usabilidade... 04/07/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 12 Prof. Dr. Rogério E. Garcia 6 FCT-UNESP 04/07/2017 BCC UML 19/04/2016 A mesma notação pode ser usada para três perspectivas diferentes: Perspectiva conceitual Perspectiva de especificação Perspectiva de implementação 04/07/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 13 BCC UML 19/04/2016 A mesma notação pode ser usada para três perspectivas diferentes: Conceitual Os diagramas são interpretados como descrevendo coisas em uma situação do mundo real ou domínio de interesse De especificação Os diagramas descrevem abstrações de software ou componentes com especificações e interfaces Sem comprometimento com uma implementação particular (LP) 04/07/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 14 Prof. Dr. Rogério E. Garcia 7 FCT-UNESP 04/07/2017 BCC UML 19/04/2016 A mesma notação pode ser usada para três perspectivas diferentes (cont.): De implementação Os diagramas descrevem implementações de software em uma tecnologia particular 04/07/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 15 BCC Diagramas da UML 19/04/2016 Diagrama Linhagem Atividades Na UML 1 Classes Na UML 1 Comunicação Colaboração da UML 1 Componentes Na UML 1 Estruturas Compostas Na UML 2 Instalação Na UML 1 Visão Geral da Interação UML 2 Objetos Extra-oficialmente na UML 1 Pacotes Extra-oficialmente na UML 1 Sequência Na UML 1 Máquinas de Estado Na UML 1 Sincronismo Na UML 2 Casos de Uso Na UML 1 04/07/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia[Fowler, 2005] 16 Prof. Dr. Rogério E. Garcia 8 FCT-UNESP 04/07/2017 Classificação dos diagramas BCC da UML Diagrama 19/04/2016 Diagrama de Diagrama de estrutura comportamento Diagrama de Diagrama de classes casos de uso Diagrama de Diagrama de objetos atividades Diagrama de sequência Diagrama de Diagrama de instalação interações Diagrama de Diagrama de Diagrama de comunicação estruturas máquina de compostas estados Diagrama de sincronização Diagrama de componentes Diagrama de visão geral da Diagrama de interação pacotes 04/07/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 17 BCC Astah 19/04/2016 Astah Community é uma ferramenta para trabalhar com diagramas UML Link de download: http://astah.change- vision.com/en/product/astah-community.html 04/07/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 18 Prof. Dr. Rogério E. Garcia 9 FCT-UNESP 04/07/2017 BCC Astah Menu 19/04/2016 Elementos de diagrama Visão do projeto Visão das Editor de propriedades diagramas 04/07/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 19 BCC Astah 19/04/2016 Menu: é o menu principal e a barra de ferramentas do Astah Visão do projeto: Estrutura (em árvore): exibe a estrutura de modelos (diagramas) Herança: exibe a estrutura de herança Mapa: exibe um editor de diagrama inteiro Diagrama: exibe uma lista de diagramas no projeto 04/07/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 20 Prof. Dr. Rogério E. Garcia 10 FCT-UNESP 04/07/2017 BCC Astah 19/04/2016 Visão das propriedades: em que é permitido a edição das propriedades dos modelos Editor de diagramas: área em que os diagramas são editados Elementos de diagrama: barra de ferramentas que disponibiliza elementos específicos para cada diagrama e elementos em comum 04/07/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 21 BCC Astah 19/04/2016 Criação de um projeto: “File” -> “New”, no menu principal ou “Create a New File”, na barra de ferramentas Criação de um projeto com um modelo: “File” -> “New By Template”, e selecione um arquivo de modelo 04/07/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 22 Prof. Dr. Rogério E. Garcia 11 FCT-UNESP 04/07/2017 BCC Astah 19/04/2016 Criação de um modelo: “Diagram”, no menu principal, e escolha um diagrama 04/07/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 23 Classificação dos diagramas BCC da UML Diagrama 19/04/2016 Diagrama de Diagrama de estrutura comportamento Diagrama de Diagrama de classes casos de uso Diagrama de Diagrama de objetos atividades Diagrama de sequência Diagrama de Diagrama de instalação interações Diagrama de Diagrama de Diagrama de comunicação estruturas máquina de compostas estados Diagrama de sincronização Diagrama de componentes Diagrama de visão geral da Diagrama de interação pacotes 04/07/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 24 Prof. Dr. Rogério E. Garcia 12 FCT-UNESP 04/07/2017 BCC Casos de Uso 19/04/2016 Os casos de uso são uma técnica para captar os requisitos funcionais de um sistema Um caso de uso é uma narrativa sobre como o sistema é utilizado por meio da descrição das interações entre os usuários de um sistema e o próprio sistema 04/07/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 25 BCC Casos de Uso – Exemplo 19/04/2016 Caso de Uso: Compra de Produto Cenário principal de sucesso: 1. O cliente navega pelo catálogo e seleciona itens para comprar 2. O cliente vai para o caixa 3. O cliente preenche o formulário da remessa (endereço de entrega; opção de entrega imediata ou em três dias) 4. O sistema apresenta a informação completa do faturamento, incluindo a remessa 04/07/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 26 Prof. Dr. Rogério E. Garcia 13 FCT-UNESP 04/07/2017 BCC Casos de Uso – Exemplo 19/04/2016 Cenário principal de sucesso (cont.): 5. O cliente preenche a informação de cartão de crédito 6. O sistema autoriza a compra 7. O sistema confirma imediatamente a venda 8. O sistema envia uma confirmação para o cliente por e-mail 04/07/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 27 BCC Casos de Uso – Exemplo 19/04/2016 Extensões: 3a. Cliente regular .1: O sistema mostra a informação atual da remessa, a informação de preço e a informação de cobrança .2: O cliente pode aceitar ou escrever por cima desses padrões, retornando ao CPS, no passo 6 6a. O sistema falha na autorização da compra a crédito .1: O cliente pode inserir novamente a informação do cartão de crédito ou cancelar 04/07/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 28 Prof.
Load more

Recommended publications
  • Component Diagrams in UML
    9. UML Component Diagrams Page 1 of 4 Component Diagrams in UML The previous articles covered two of the three primary areas in which the UML diagrams are categorized (see Article 1)—Static and Dynamic. The remaining two UML diagrams that fall under the category of Implementation are the Component and Deployment diagrams. In this article, we will discuss the Component diagram. Basics The different high-level reusable parts of a system are represented in a Component diagram. A component is one such constituent part of a system. In addition to representing the high-level parts, the Component diagram also captures the inter- relationships between these parts. So, how are component diagrams different from the previous UML diagrams that we have seen? The primary difference is that Component diagrams represent the implementation perspective of a system. Hence, components in a Component diagram reflect grouping of the different design elements of a system, for example, classes of the system. Let us briefly understand what criteria to apply to model a component. First and foremost, a component should be substitutable as is. Secondly, a component must provide an interface to enable other components to interact and use the services provided by the component. So, why would not a design element like an interface suffice? An interface provides only the service but not the implementation. Implementation is normally provided by a class that implements the interface. In complex systems, the physical implementation of a defined service is provided by a group of classes rather than a single class. A component is an easy way to represent the grouping together of such implementation classes.
    [Show full text]
  • Using the UML for Architectural Description?
    Using the UML for Architectural Description? Rich Hilliard Integrated Systems and Internet Solutions, Inc. Concord, MA USA [email protected] Abstract. There is much interest in using the Unified Modeling Lan- guage (UML) for architectural description { those techniques by which architects sketch, capture, model, document and analyze architectural knowledge and decisions about software-intensive systems. IEEE P1471, the Recommended Practice for Architectural Description, represents an emerging consensus for specifying the content of an architectural descrip- tion for a software-intensive system. Like the UML, IEEE P1471 does not prescribe a particular architectural method or life cycle, but may be used within a variety of such processes. In this paper, I provide an overview of IEEE P1471, describe its conceptual framework, and investigate the issues of applying the UML to meet the requirements of IEEE P1471. Keywords: IEEE P1471, architectural description, multiple views, view- points, Unified Modeling Language 1 Introduction The Unified Modeling Language (UML) is rapidly maturing into the de facto standard for modeling of software-intensive systems. Standardized by the Object Management Group (OMG) in November 1997, it is being adopted by many organizations, and being supported by numerous tool vendors. At present, there is much interest in using the UML for architectural descrip- tion: the techniques by which architects sketch, capture, model, document and analyze architectural knowledge and decisions about software-intensive systems. Such techniques enable architects to record what they are doing, modify or ma- nipulate candidate architectures, reuse portions of existing architectures, and communicate architectural information to others. These descriptions may the be used to analyze and reason about the architecture { possibly with automated support.
    [Show full text]
  • Plantuml Language Reference Guide (Version 1.2021.2)
    Drawing UML with PlantUML PlantUML Language Reference Guide (Version 1.2021.2) PlantUML is a component that allows to quickly write : • Sequence diagram • Usecase diagram • Class diagram • Object diagram • Activity diagram • Component diagram • Deployment diagram • State diagram • Timing diagram The following non-UML diagrams are also supported: • JSON Data • YAML Data • Network diagram (nwdiag) • Wireframe graphical interface • Archimate diagram • Specification and Description Language (SDL) • Ditaa diagram • Gantt diagram • MindMap diagram • Work Breakdown Structure diagram • Mathematic with AsciiMath or JLaTeXMath notation • Entity Relationship diagram Diagrams are defined using a simple and intuitive language. 1 SEQUENCE DIAGRAM 1 Sequence Diagram 1.1 Basic examples The sequence -> is used to draw a message between two participants. Participants do not have to be explicitly declared. To have a dotted arrow, you use --> It is also possible to use <- and <--. That does not change the drawing, but may improve readability. Note that this is only true for sequence diagrams, rules are different for the other diagrams. @startuml Alice -> Bob: Authentication Request Bob --> Alice: Authentication Response Alice -> Bob: Another authentication Request Alice <-- Bob: Another authentication Response @enduml 1.2 Declaring participant If the keyword participant is used to declare a participant, more control on that participant is possible. The order of declaration will be the (default) order of display. Using these other keywords to declare participants
    [Show full text]
  • APECS: Polychrony Based End-To-End Embedded System Design and Code Synthesis
    APECS: Polychrony based End-to-End Embedded System Design and Code Synthesis Matthew E. Anderson Dissertation submitted to the faculty of the Virginia Polytechnic Institute and State University in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Computer Engineering Sandeep K. Shukla, Chair Lamine Mili Alireza Haghighat Chao Wang Yi Deng April 3, 2015 Blacksburg, Virginia Keywords: AADL, CPS, Model-based code synthesis, correct-by-construction code synthesis, Polychrony, code generators, OSATE, Ocarina Copyright 2015, Matthew E. Anderson APECS: Polychrony based End-to-End Embedded System Design and Code Synthesis Matthew E. Anderson (ABSTRACT) The development of high integrity embedded systems remains an arduous and error-prone task, despite the efforts by researchers in inventing tools and techniques for design automa- tion. Much of the problem arises from the fact that the semantics of the modeling languages for the various tools, are often distinct, and the semantics gaps are often filled manually through the engineer's understanding of one model or an abstraction. This provides an op- portunity for bugs to creep in, other than standardising software engineering errors germane to such complex system engineering. Since embedded systems applications such as avionics, automotive, or industrial automation are safety critical, it is very important to invent tools, and methodologies for safe and reliable system design. Much of the tools, and techniques deal with either the design of embedded platforms (hardware, networking, firmware etc), and software stack separately. The problem of the semantic gap between these two, as well as between models of computation used to capture semantics must be solved in order to design safer embedded systems.
    [Show full text]
  • Systems Engineering with Sysml/UML Morgan Kaufmann OMG Press
    Systems Engineering with SysML/UML Morgan Kaufmann OMG Press Morgan Kaufmann Publishers and the Object Management Group™ (OMG) have joined forces to publish a line of books addressing business and technical topics related to OMG’s large suite of software standards. OMG is an international, open membership, not-for-profi t computer industry consortium that was founded in 1989. The OMG creates standards for software used in government and corporate environments to enable interoperability and to forge common development environments that encourage the adoption and evolution of new technology. OMG members and its board of directors consist of representatives from a majority of the organizations that shape enterprise and Internet computing today. OMG’s modeling standards, including the Unifi ed Modeling Language™ (UML®) and Model Driven Architecture® (MDA), enable powerful visual design, execution and maintenance of software, and other processes—for example, IT Systems Modeling and Business Process Management. The middleware standards and profi les of the Object Management Group are based on the Common Object Request Broker Architecture® (CORBA) and support a wide variety of industries. More information about OMG can be found at http://www.omg.org/. Related Morgan Kaufmann OMG Press Titles UML 2 Certifi cation Guide: Fundamental and Intermediate Exams Tim Weilkiens and Bernd Oestereich Real-Life MDA: Solving Business Problems with Model Driven Architecture Michael Guttman and John Parodi Architecture Driven Modernization: A Series of Industry Case Studies Bill Ulrich Systems Engineering with SysML/UML Modeling, Analysis, Design Tim Weilkiens Acquisitions Editor: Tiffany Gasbarrini Publisher: Denise E. M. Penrose Publishing Services Manager: George Morrison Project Manager: Mónica González de Mendoza Assistant Editor: Matt Cater Production Assistant: Lianne Hong Cover Design: Dennis Schaefer Cover Image: © Masterfile (Royalty-Free Division) Morgan Kaufmann Publishers is an imprint of Eslsevier.
    [Show full text]
  • Component Diagrams
    1.COMPONENT DIAGRAMS 2. PACKAGE DIAGRAMS What is a component? – A component is an autonomous unit within a system – UML component diagrams enable to model the high-level software components, and the interfaces to those components – Important for component-based development (CBD) – Component and subsystems can be flexibly REUSED and REPLACED – UML components diagrams are Implementation diagrams i.e., it describe the different elements required for implementing a system Example – When you build a house, you must do more than create blueprints – you've got to turn your floor plans and elevation drawings into real walls, floors, and ceilings made of wood, stone, or metal. – If you are renovating a house, you'll reuse even larger components, such as whole rooms and frameworks. – Same is the case when we develop software…. COMPONENT NOTATION – A component is shown as a rectangle with – A keyword <<component>> – Optionally, in the right hand corner a component icon can be displayed – A component icon is a rectangle with two smaller rectangles jutting out from the left-hand side – This symbol is a visual stereotype – The component name Component types Components in UML could represent – logical components (e.g., business components, process components) – physical components (e.g., EJB components, COM+ and .NET components) Component ELEMENTS – A component can have – Interfaces An interface represents a declaration of a set of operations – Usage dependencies A usage dependency is relationship which one element requires another element for its full
    [Show full text]
  • UML Basics: the Component Diagram
    English Sign in (or register) Technical topics Evaluation software Community Events UML basics: The component diagram Donald Bell ([email protected]), IT Architect, IBM Corporation Summary: from The Rational Edge: This article introduces the component diagram, a structure diagram within the new Unified Modeling Language 2.0 specification. Date: 15 Dec 2004 Level: Introductory Also available in: Chinese Vietnamese Activity: 259392 views Comments: 3 (View | Add comment - Sign in) Average rating (629 votes) Rate this article This is the next installment in a series of articles about the essential diagrams used within the Unified Modeling Language, or UML. In my previous article on the UML's class diagram, (The Rational Edge, September 2004), I described how the class diagram's notation set is the basis for all UML 2's structure diagrams. Continuing down the track of UML 2 structure diagrams, this article introduces the component diagram. The diagram's purpose The component diagram's main purpose is to show the structural relationships between the components of a system. In UML 1.1, a component represented implementation items, such as files and executables. Unfortunately, this conflicted with the more common use of the term component," which refers to things such as COM components. Over time and across successive releases of UML, the original UML meaning of components was mostly lost. UML 2 officially changes the essential meaning of the component concept; in UML 2, components are considered autonomous, encapsulated units within a system or subsystem that provide one or more interfaces. Although the UML 2 specification does not strictly state it, components are larger design units that represent things that will typically be implemented using replaceable" modules.
    [Show full text]
  • Examples of UML Diagrams
    UML Diagrams Examples Examples by Technology or Application Domain Online shopping UML diagrams Ticket vending machine UML diagrams Bank ATM UML diagrams Hospital management UML diagrams Digital imaging and communications in medicine (DICOM) UML diagrams Java technology UML diagrams Application development for Android UML diagrams Software licensing and protection using SafeNet Sentinel HASP security solution Examples by Types of Diagrams Activity diagram examples Class diagram examples Communication diagram examples Component diagram examples Composite structure diagram examples Deployment diagram examples Information flow diagram example Interaction overview diagram examples Object diagram example Package diagram examples Profile diagram examples http://www.uml-diagrams.org/index-examples.html 1/15/17, 1034 AM Page 1 of 33 Sequence diagram examples State machine diagram examples Timing diagram examples Use case diagram examples Use Case Diagrams Business Use Case Diagrams Airport check-in and security screening business model Restaurant business model System Use Case Diagrams Ticket vending machine http://www.uml-diagrams.org/index-examples.html 1/15/17, 1034 AM Page 2 of 33 Bank ATM UML use case diagrams examples Point of Sales (POS) terminal e-Library online public access catalog (OPAC) http://www.uml-diagrams.org/index-examples.html 1/15/17, 1034 AM Page 3 of 33 Online shopping use case diagrams Credit card processing system Website administration http://www.uml-diagrams.org/index-examples.html 1/15/17, 1034 AM Page 4 of 33 Hospital
    [Show full text]
  • UML Why Develop a UML Model?
    App Development & Modelling BSc in Applied Computing Produced Eamonn de Leastar ([email protected]) by Department of Computing, Maths & Physics Waterford Institute of Technology http://www.wit.ie http://elearning.wit.ie Introduction to UML Why develop a UML model? • Provide structure for problem solving • Experiment to explore multiple solutions • Furnish abstractions to manage complexity • Decrease development costs • Manage the risk of mistakes #3 The Challenge #4 The Vision #5 Why do we model graphically? " Graphics reveal data.! " Edward Tufte$ The Visual Display of Quantitative Information, 1983$ " 1 bitmap = 1 megaword.! " Anonymous visual modeler #6 Building Blocks of UML " The basic building blocks of UML are:! " model elements (classes, interfaces, components, use cases, etc.)! " relationships (associations, generalization, dependencies, etc.)! " diagrams (class diagrams, use case diagrams, interaction diagrams, etc.)! " Simple building blocks are used to create large, complex structures! " eg elements, bonds and molecules in chemistry! " eg components, connectors and circuit boards in hardware #7 Example : Classifier View #8 Example: Instance View #9 UML Modeling Process " Use Case! " Structural! " Behavioural! " Architectural #10 Use Case Visual Paradigm Help #11 Structural Modeling Visual Paradigm Help #12 Behavioural Modeling Visual Paradigm Help #13 Architectural Modeling Visual Paradigm Help #14 Structural Modeling " Core concepts! " Diagram Types #15 Structural Modeling Core Elements " a view of an system that emphasizes
    [Show full text]
  • TAGDUR: a Tool for Producing UML Sequence, Deployment, and Component Diagrams Through Reengineering of Legacy Systems
    TAGDUR: A Tool for Producing UML Sequence, Deployment, and Component Diagrams Through Reengineering of Legacy Systems Richard Millham, Jianjun Pu, Hongji Yang De Montfort University, England [email protected] & [email protected] Abstract: A further introduction of TAGDUR, a documents this transformed system through a reengineering tool that first transforms a series of UML diagrams. This paper focuses on procedural legacy system into an object-oriented, TAGDUR’s generation of sequence, deployment, event-driven system and then models and and component diagrams. Keywords: UML (Unified Modeling Language), Reengineering, WSL This paper is a second installment in a series [4] accommodate a multi-tiered, Web-based that introduces TAGDUR (Transformation and platform. In order to accommodate this Automatic Generation of Documentation in remodeled platform, the original sequential- UML through Reengineering). TAGDUR is a driven, procedurally structured legacy system reengineering tool that transforms a legacy must be transformed to an object-oriented, event- system’s outmoded architecture to a more driven system. Object orientation, because it modern one and then represents this transformed encapsulates variables and procedures into system through a series of UML (Unified modules, is well suited to this new Web Modeling Language) diagrams in order to architecture where pieces of software must be overcome a legacy system’s frequent lack of encapsulated into component modules with documentation. The architectural transformation clearly defined interfaces. A transfer to a Web- is from the legacy system’s original based architecture requires a real-time, event- procedurally-structured to an object-oriented, driven response rather than the legacy system’s event-driven architecture.
    [Show full text]
  • UML Meets CORBA Page 1 Design of a Fault-Tolerant Distributed System Version 1.0
    UML meets CORBA Page 1 Design of a fault-tolerant distributed system Version 1.0 UML Meets CORBA Design of a fault-tolerant distributed system By: Craig Borysowich Chief Technology Architect Imagination Edge Inc. www.imedge.net Page 1 of 43 UML meets CORBA Page 2 Design of a fault-tolerant distributed system Version 1.0 Executive Summary This paper presents the development of a distributed fault-tolerant system, in a CORBA environment, using the Unified Modeling Language (UML). The paper is useful as (1) an example of actual modeling using the UML and (2) a non-trivial example of modeling distributed fault-tolerant object distributed systems for a CORBA environment. The example application is part of a commodity trading environment, supporting individual traders in a commodity trading environment, and focuses on two functions: the monitoring and gathering of market information, and the completion of a commodity trade. The application has significant requirements regarding distribution and fault-tolerance. The modeling building and presentation is organized into three layers: a domain analysis model, a design architecture, and a packaging and deployment model. The emphasis of the modeling exercise is on the architectural design layer, and the emphasis of the design is on the representation of services in a CORBA system. We use seven types of UML diagrams in our example: use case diagrams, class diagrams, sequence diagrams, state transition diagrams, collaboration diagrams, component diagrams, and deployment diagrams. Page 2 of 43 UML meets CORBA Page 3 Design of a fault-tolerant distributed system Version 1.0 Table of Contents 1. Introduction .................................................................................................................................................5 1.1.
    [Show full text]
  • UML Basics: the Component Diagram
    IBM Copyright http://www.ibm.com/developerworks/rational/library/dec04/bell/index.html Country/region [select] Terms of use All of dW Home Products Services & solutions Support & downloads My account developerWorks > Rational > UML basics: The component diagram Level: Introductory Contents: The diagram's purpose Donald Bell The notation IBM Global Services, IBM The basics 15 Dec 2004 Beyond the basics from The Rational Edge: This article introduces the component diagram, a structure diagram Conclusion within the new Unified Modeling Language 2.0 specification. Notes About the author This is the next installment in a series of articles about the essential diagrams used within the Unified Modeling Language, Rate this article or UML. In my previous article on the UML’s class diagram, Subscriptions: (The Rational Edge, September 2004), I described how the dW newsletters class diagram’s notation set is the basis for all UML 2’s structure diagrams. Continuing down the track of UML 2 structure dW Subscription diagrams, this article introduces the component diagram. (CDs and downloads) The Rational Edge The diagram's purpose The component diagram’s main purpose is to show the structural relationships between the components of a system. In UML 1.1, a component represented implementation items, such as files and executables. Unfortunately, this conflicted with the more common use of the term “component," which refers to things such as COM components. Over time and across successive releases of UML, the original UML meaning of components was mostly lost. UML 2 officially changes the essential meaning of the component concept; in UML 2, components are considered autonomous, encapsulated units within a system or subsystem that provide one or more interfaces.
    [Show full text]