Desenvolvimento de Software Baseado em Componentes. Paulo C. Masiero

Documentos relacionados
Desenvolvimento de Software Baseado em Componentes. Paulo C. Masiero

(Engenharia de) Requisitos. Cheesman Cp 4

Identificação de Componentes

Visões Arquiteturais. Visões Arquiteturais

15/04/2013. Pensar Orientado a Objetos. Projeto Orientado a Objetos. Características de Objetos. Classe de Objetos. Comunicação entre Objetos

DIAGRAMAS DE CLASSE UML

RUP RATIONAL UNIFIED PROCESS

2

CBSE. Independência e Padronização. Características da CBSE. Fundamentos da CBSE. Middleware e Processo 22/05/2013

3 Uma Abordagem Orientada a Aspectos para o Desenvolvimento de Frameworks

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE CAMPI JOÃO CÂMARA RATIONAL UNIFIED PROCESS - RUP

Visão Geral da UML. SSC Engenharia de Software I Profa. Dra. Elisa Yumi Nakagawa 2 o semestre de 2012

Engenharia de Software

Curso de Sistemas de Informação. Karla Donato Fook DESU / DComp. Modelagem de Dados UML

Reuso de Software Aula Maio 2012

INF1013 MODELAGEM DE SOFTWARE

Engenharia de Software. Projeto de Arquitetura

MANUAL PARA DESENVOLVIMENTO DE SOFTWARE TRABALHO DE CONCLUSAO DE CURSO EM SISTEMAS DE INFORMAÇÃO

Engenharia de Software Orientada a Serviços

Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto

4.6. UML Diagramas de componentes

Requisitos de sistemas

Arquitetura de software

Visões Arquiteturais. Arquitetura de Software Thaís Batista

Prof. Fábio Lúcio Meira

Engenharia de Software Processo de Desenvolvimento. Ciclo de Vida - Modelo Cascata

Engenharia de Software Orientada a Serviços

Processos de Software

EA975 - Laboratório de Engenharia de Software

Visões Arquiteturais. Visões Arquiteturais. Visões Arquiteturais. Visão Conceitual

Um Método para o Desenvolvimento de Software Baseado em Componentes e Aspectos

Introdução ao método de projeto OO. Prof. Cesar Augusto Tacla

Introdução ao método de projeto OO

RUP Unified Process. Profª Jocelma Rios

Introdução a UML (Unified Modeling Language)

UML (Linguagem Modelagem Unificada) João Paulo Q. dos Santos

2 Fluxos no Ciclo de Vida do Processo Unificado. O Processo Unificado consiste da repetição de uma série de ciclos durante a vida de um sistema.

3 Kaluana Arquitetura

Análise e projeto de sistemas

DESENVOLVIMENTO BASEADO EM COMPONENTES

PROJETO DE ARQUITETURA

Processos de Software

Visão Geral do RUP.

Apresentação do Capítulo 4 MDA (Model-Driven Archtecture) ALUNO: DOMENICO SCHETTINI FILHO NÚMERO USP:

INF014 Análise e Projeto de Sistemas Processos Unificado -RUP

Processos de Software by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1

5 Processo de Reificação e de Desenvolvimento com ACCA

Diagrama de Componentes

Análise e Projeto de Software

Engenharia de Requisitos

Aula 4 Engenharia de Requisitos

Por que é importante?

Interação dos Componentes

Departamento de Sistemas de Computação Universidade de São Paulo Análise e Projeto Orientados a Objetos Aula 2 O Processo Unificado (PU)

Documento de Arquitetura de Software- SGE

O Processo Unificado (PU) SSC 121 Engenharia de Software I Profa. Dra. Elisa Yumi Nakagawa 2 o semestre de 2012

Introdução à Análise e Projeto de Sistemas

O Processo Unificado: Workflow de Análise. Graduação em Informática Profa. Dra. Itana Maria de Souza Gimenes 2009

ARQUITETURA E DESENHO

SABiO: Systematic Approach for Building Ontologies

SOFTWARE REQUIREMENTS

Metamodelos para Banco de Dados. Carlos Julian Menezes Araújo Prof. Dr. Robson do Nascimento Fidalgo

UML 2.0 Método, Linguagem e Ferramenta. Prof. Cesar Augusto Tacla

Processos de Engenharia de Requisitos

Introdução. Conceitos Básicos. Conceitos Básicos. Conceitos Básicos

Tarefas de Gerenciamento de Configuração

Introdução ao RUP Rational Unified Process

UML (Unified Modelling Language)

PUC-GO- ADS: Prof. Vicente P. de Camargo. Desenvolvimento de Aplicações para Cliente Servidor

Arquitetura de Software visão emergente

Engenharia de Software II

Modelagem Orientada a Objetos

Ferramenta MVCase Uma Ferramenta Integradora de Tecnologias para o Desenvolvimento de Componentes Distribuídos

DIVISÃO DE ASSUNTOS ACADÊMICOS Secretaria Geral de Cursos PROGRAMA DE DISCIPLINA

Engenharia de Software

SSC Engenharia de Software. Prof. Paulo C. Masiero

Introdução à Qualidade de Software

Aula 13 Modelagem da Arquitetura

Modelagem de dados usando MER. Andre Noel

Engenharia de Software.

Introdução à Engenharia de Software

Engenharia de Software

Fases do OOHDM. OOHDM Um modelo para autoria de HT

ISO/IEC Roteiro IEC ISO. Histórico ISO/IEC ISO

FUNDAÇÃO UNIVERSIDADE ESTADUAL DE MARINGÁ

Professor Emiliano S. Monteiro

FURBUP: UM PROCESSO DE SOFTWARE PARA USO ACADÊMICO BASEADO NO OPENUP. Acadêmico: João Paulo Pedri Orientador: Everaldo Artur Grahl

Especificação de Sistemas de Software e a UML

Visão Geral do RUP (Rational Unified Process)

Processo de Desenvolvimento

Introdução. Conceitos Básicos. Conceitos Básicos. Conceitos Básicos

Exemplo: Documento de Arquitetura de Software

Processo Unificado. Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior

Tópicos da Aula. Conceitos de programação orientada a objetos. Projeto orientado a objetos com UML

Processos de. Desenvolvimento de Software

DS: notação. Falta-nos apenas dar exemplos de DSS que contenham a criação de objectos temporários e sua posterior destruição.

Processos de software

RUP/PSDS. Introdução e Comparação

Transcrição:

Desenvolvimento de Software Baseado em Componentes Paulo C. Masiero 1

Introdução Frustração com as promessas da Orientação a objetos em relação ao reuso de classes. Frameworks são uma solução para um domínio específico que consideram uma arquitetura OO composta de várias classes. DSBC surgiu nos anos 90 como uma solução mais ampla e independente. 2

Introdução DSBC: processo de definição, implantação e integração ou composição de componentes independentes, não firmemente acoplados ao sistema. DSBC tem quatro pontos principais: Componentes independentes. Padrões de componentes. Middlewares para apoiar a integração. Processo de desenvolvimento. 3

Problemas Confiabilidade dos componentes Certificação de componentes Previsão de propriedades emergentes Compromisso de requisitos (como selecionar e configurar componentes?) 4

Componentes e modelos de componentes Um componente de software é uma unidade de composição com interfaces contratualmente especificadas e dependências de contexto explícitas. Um componente de software pode ser implantado independentemente e está sujeito a composição por terceiros É uma unidade executável independentemente. Os serviços oferecidos são disponibilizados somente por meio de uma interface. 5

O processo de DSBC Há alguns métodos propostos para o DSBC UML Components Catalysis Em linhas gerais: Especificar os requisitos do sistema (é preciso um conjunto completo) Refinar e modificar os requisitos, dependendo dos componentes disponíveis Projetar a arquitetura do sistema e buscar componentes Desenvolver compondo os componentes 6

Formas de componentes A visão do componente muda durante o ciclo de vida do projeto Há diversas formas de componentes e cada uma reflete algum aspecto do componente durante o ciclo de desenvolvimento Definição das diversas formas do componente, ao invés de definição de componente 7

Formas de componentes Ex. MS Word suporttedinterface 1..* Interface de componente Definição de um conjunto de comportamentos que podem ser oferecidos por um objeto componente * Especificação de componente 1 * concretização Implementação de componente 1 * instalação Componente instalado 1 * instância Objeto componente Especificação de uma unidade de software que descreve o comportamento de um conjunto de objetos componentes e define uma unidade de implementação Concretização Uma implementação de uma especificação de componente. registrada Pode no ambiente ser instalado e substituído de execução independentemente de outros componentes Uma instância de um componente instalado. Executa o comportamento implementado 8

Formas de componentes Em tempo de execução o componente possui conteúdo (estado) Além dos serviços providos pelo componente, a informação gerenciada também é importante Na substituição do componente deve-se garantir os serviços e as informações 9

Arquiteturas de Sistema e de Componentes Arquitetura de sistema Estrutura das partes que compõem uma instalação completa de software (incluindo responsabilidades, interconexões, etc) 10

Arquiteturas de Sistema e de Componentes Arquiteturas de componente Um conjunto de componentes de software, seus relacionamentos estruturais e suas dependências de comportamento (nível de aplicação) 11

Arquiteturas de Componentes Arquitetura de objeto componente Especifica as instâncias do componente que serão acessadas :OrderMgr :Stock Control :OrderMgr :Stock Control :ProductMgr ordering :ProductMgr stockctl :ProductMgr 12

Contratos de uso e de implementação 13

Contratos de uso Lista das operações Cada operação, além da sua assinatura é definida por uma pré-condição e uma póscondição (Pode ser usado OCL para isso). Modelo de Informação : informação ou estado que é mantido (persistido) entre requisições de clientes. 14

Processo de Desenvolvimento Business requirements Requirements Business concept models Gera um conjunto de especificações de componentes e uma arquitetura de Existing assets componentes Technical constraints Use case models Components Junta os componentes com softwares existentes e interface, produzindo a aplicação Specification Provisioning Assembly Component specs & architectures Assegura que os Use case models componentes necessários estejam disponíveis (compra, reuso, desenvolvimento) Test Applications Tested applications Deployment 15

Sub-processos (ou workflows) Requisitos Definição de Requisitos? Modelo de conceito de negócio? Modelo de caso de uso Especificação Identificação de Componentes? Modelo de tipo de negócio? Especificações de interface? Especificações de componente? Arquitetura de componente Interação de Componentes Especificação de Componentes Fornecimento Provisionamento Montagem 16

Artefatos do processo Requisitos Modelo de conceitos de negócio Cria um vocabulário comum entre os envolvidos no projeto Modelo de casos de uso Descreve as interações entre um usuário e o sistema e auxilia na identificação dos limites do sistema 17

Artefatos do processo Especificação Modelo de tipos de negócio Formaliza o modelo de conceito de negócio e define o conhecimento que o sistema possui do mundo externo Especificações de interface Conjunto de especificações de interface Cada especificação de interface é um contrato com um cliente de um objeto componente 18

Artefatos do processo Especificação Especificações de componente Conjunto de especificações de componente Cada especificação de componente é definida em termos de especificações e restrições Arquitetura de componente Descreve como especificações de componentes são combinadas em uma determinada configuração 19

Modelo do conceito do negócio ESPECIFICAÇAO Arquitetura inicial de componentes a partir dos requisitos Desenvolver modelo de tipo do sistema Modelo de casos de uso Identificação de componentes Interfaces existentes Identificar interfaces de negócios Identificar interfaces de sistema e operações Operações necessárias e alocação de responsabilidades Assets existentes Interfaces de negócios Modelo de tipo de negócio Descobrir operações de negócio Interfaces Criar especificação e arquitetura inicial dos componentes Refinar interfaces e operações Padrões de arquitetura Interação de componentes Refinar especificação e arquitetura dos componentes Especificação precisa das operações, interfaces e componentes Definir interface dos modelos de informação Especificar pré- e póscondições das operações Especificação de componentes Especificar restrições Componete-interface Especificações e arquiteturas dos componentes Interfaces Especificações e arquiteturas dos componentes 20

Processo de especificação Identificação de componente Identifica um conjunto inicial de interfaces de negócios (componentes de negócios) e interfaces de sistema (componentes de sistema) Junta as interfaces em uma arquitetura de componente inicial Operações que deverão ser apoiadas pelo sistema 21

Processo de especificação Interação de componente Examina como cada operação do sistema será alcançada, usando a arquitetura de componente Operações são movidas entre interfaces Detalhes completos da estrutura do sistema Entendimento das dependências entre componentes 22

Processo de especificação Especificação de componente Especificação detalhada das operações e restrições Para cada interface, definição dos potenciais estados dos objetos componentes num modelo de informação de interface e especificação das pré- e pós-condições das operações e captura dos papéis de negócio como restrições 23

Notação utilizada: UML Tipos de Interface <<interface type>> Nome prefixado por um I Especificação de Interfaces Tipos de dados estruturados 24

<<interface>> da UML pode implementar um tipo de interface 25

26

Modelos de Informação Objetivos: definir interfaces independentes Modelos de tipos de negócios Tipos de informação <<info type>> Um único modelo integrado Os tipos são exclusivos de cada interface 27

Especificação de interfaces 28

Especificação de Componente Oferece um conjunto de tipos de interface Usa o estereótipo: <<comp spec>> Um diagrama de especificação de componente foca em uma única especificação de componente e detalha suas dependências individuais. 29

Modelos de Informação Especificação de operação Uma assinatura é composta por um ou mais parâmetros Tipos de dados são sempre passados por valor. Possui uma assinatura com 0 ou mais parâmetros tipados 30

Interação de instâncias (objetos) de componentes 31

Arquitetura de componentes: 32

Arquitetura de Objeto componente Especifica as instâncias que serão acessadas 33

O processo de projeto (design) Definição dos Requisitos 34

(Engenharia de) requisitos 35

Processo de negócio para reservar um quarto em hotel 36

Modelo Conceitual 37

Descrição do Sistema de Reserva de Hotel Deseja-se desenvolver um sistema de reserva de hotel a ser feito para qualquer hotel de uma cadeia. Presentemente cada hotel tem seu próprio sistema de reservas e eles são incompatíveis entre si. As reservas podem ser feitas por telefone a uma central de reservas ou diretamente em cada hotel ou pela Internet. A maior vantagem do sistema será oferecer acomodações em hotel alternativos quando o desejado está cheio. Cada hotel terá suas próprias instalações para fazer reservas na recepção, no escritório e na mesa do porteiro. Cada hotel tem um administrador de reservas que é responsável por controlar as reservas do hotel, mas qualquer usuário autorizado poderá fazer reservas. O tempo esperado para completar uma reserva por telefone é 3m. Para agilizar o processo, os detalhes de clientes anteriores serão armazenados e tornados disponíveis. 38

Casos de use Modelo de Processo de Negócio com responsabilidades 39

Diagrama de Casos de Uso 40

41

42

43