UML Components - A Simple Process for Specifying



Documentos relacionados
MVC e Camadas - Fragmental Bliki

Projeto de Arquitetura

3.1 Definições Uma classe é a descrição de um tipo de objeto.

Engenharia de Software. Parte I. Introdução. Metodologias para o Desenvolvimento de Sistemas DAS

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 14 PROFª BRUNO CALEGARO

Conceitos de Banco de Dados

Aula 2 Revisão 1. Ciclo de Vida. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW

Padrões de projeto 1

ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA

Autoria:Aristófanes Corrêa Silva Adaptação: Alexandre César M de Oliveira

2 a Lista de Exercícios

Projeto de Sistemas I

Modelagemde Software Orientadaa Objetos com UML

3. Fase de Planejamento dos Ciclos de Construção do Software

2 Diagrama de Caso de Uso

Introdução ao Modelos de Duas Camadas Cliente Servidor

Metadados. 1. Introdução. 2. O que são Metadados? 3. O Valor dos Metadados

Modelagem de Processos. Prof.: Fernando Ascani

Análise e Desenvolvimento de Sistemas ADS Programação Orientada a Obejeto POO 3º Semestre AULA 03 - INTRODUÇÃO À PROGRAMAÇÃO ORIENTADA A OBJETO (POO)

Introdução! 1. Modelos de Domínio! 1. Identificação de classes conceituais! 2. Estratégia para identificar classes conceituais! 2

TechProf Documento de Arquitetura

Análise e Projeto Orientados a Objeto

4. Qual seria o impacto da escolha de uma chave que possua letras repetidas em uma cifra de transposição?

SISTEMA GERENCIADOR DE BANCO DE DADOS

Introdução ao RUP Rational Unified Process. por Denize Terra Pimenta Outubro/2004

Tópicos de Ambiente Web. Modulo 2 Processo de desenvolvimento de um site Professora: Sheila Cáceres

Persistência e Banco de Dados em Jogos Digitais

Eduardo Bezerra. Editora Campus/Elsevier

A Linguagem de Modelagem Unificada (UML)

Introdução à Engenharia de Software

Desenvolvimento estruturado versus orientado a objetos.

Simulador de Financiamento. Versão: 1.0 Data: 26/05/14 Identificador do documento: SF

Simulador de Pagamento

04/08/2012 MODELAGEM DE DADOS. PROF. RAFAEL DIAS RIBEIRO, MODELAGEM DE DADOS. Aula 2. Prof. Rafael Dias Ribeiro. M.Sc.

Princípios da Engenharia de Software Aula 02. Prof.: Franklin M. Correia

Metodologia e Gerenciamento do Projeto na Fábrica de Software v.2

Figura 5 - Workflow para a Fase de Projeto

Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços. Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena

Engenharia de Requisitos Estudo de Caso

ENG1000 Introdução à Engenharia

Programação com acesso a BD. Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP)

Conteúdo. Disciplina: INF Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite (81 )

PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB)

Sistema de Digitalização e Gerenciamento de Arquivos On-Line

Modelagem Conceitual Exercício resolvido 02 Modelagem Conceitual

Utilizando os Diagramas da UML (Linguagem Unificada de Modelagem) para desenvolver aplicação em JSF

UML - Unified Modeling Language

Análise e Projeto Orientado a Objetos. Modelagem de Domínio

Fábrica de Software 29/04/2015

Backup. Permitir a recuperação de sistemas de arquivo inteiros de uma só vez. Backup é somente uma cópia idêntica de todos os dados do computador?

Documento de Projeto de Software

Sistemas Operacionais

SAV Sistema de Aluguel de Veículos I - DOCUMENTO DE REQUISITOS Versão 1.00

3. Explique o motivo pelo qual os protocolos UDP e TCP acrescentam a informação das portas (TSAP) de origem e de destino em seu cabeçalho.

Gerenciamento de Requisitos Gerenciamento de Requisitos

Manual BizAgi Sistema de Gestão da Qualidade

SISTEMA DE GERENCIAMENTO DE PROJETOS - REDMINE MANUAL DE USO

Processo de Desenvolvimento Unificado

Diagrama de transição de Estados (DTE)

Projeto Disciplinar de Infra-Estrutura de Software ECOFROTA TRIBUNAL THEMIS

Concepção e Elaboração

Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software

Introdução ao Aplicativo de Programação LEGO MINDSTORMS Education EV3

Documento de Arquitetura

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

Ferramenta de apoio a gerência de configuração de software. Aluno: Rodrigo Furlaneto Orientador: Everaldo Artur Grahl

MÓDULO 8 ARQUITETURA DOS SISTEMAS DE BANCO DE DADOS

SISTEMA TYR DIAGRAMAS DE CLASSE E SEQUÊNCIA Empresa: Academia Universitária

Feature-Driven Development

1 Introdução. Componentes Usuários. Provedor de Serviços. Figura 1.1 Ambiente de oferecimento de serviços

Boas Práticas de Desenvolvimento Seguro

Tema 1: Modelo Estático

LINGUAGEM DE BANCO DE DADOS

Análise de Sistemas. Visão Geral: Orientação a Objetos. Prof. José Honorato Ferreira Nunes honorato.nunes@bonfim.ifbaiano.edu.br

CAPÍTULO 7 NÍVEL DE LINGUAGEM DE MONTAGEM

MODELAGEM DE DADOS. Unidade II Arquiteturas do SGBD

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0

UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO. Contribuições do MDA para o desenvolvimento de software

ENGENHARIA DA COMPUTAÇÃO

Documento de Projeto de Sistema

ADMINISTRAÇÃO DE ATIVOS DE TI GERENCIAMENTO DE CONFIGURAÇÃO

Curso Superior de Tecnologia em Banco de Dados e Sistemas para Internet Disciplina: Projeto Integrador III Prof.: Fernando Hadad Zaidan

AGENDA. O Portal Corporativo. Arquitetura da Informação. Metodologia de Levantamento. Instrumentos Utilizados. Ferramentas

Diagrama de Casos de Uso. Diagrama de Casos de Uso. Diagrama de Casos de Uso. Diagrama de Casos de Uso. Componentes do Diagrama

Modelo Entidade-Relacionamento

Engenharia de Software Aula 7 (Versão )

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação

ENGENHARIA DE SOFTWARE I

Franklin Ramalho Universidade Federal de Campina Grande - UFCG

Introdução ao OpenUP (Open Unified Process)

Análise e Projeto Orientados a Objetos Aula IV Requisitos. Prof.: Bruno E. G. Gomes IFRN

Módulo 4: Gerenciamento de Dados

ISO/IEC 12207: Gerência de Configuração

Transcrição:

UML Components - A Simple Process for Specifying Component-Based Software Lucas Monteiro Braz lmonteirobraz@gmail.com São Leopoldo 17 de março de 2010

Components aren t rocket science Contudo, há grande confusão sobre os conceitos de componentes

Objetivos dos Componentes O principal objetivo dos componentes NÃO é reuso!!! O principal objetivo é que os componentes sejam facilmente substituídos Por outro componente completamente diferente Ou por uma versão atualizada do componente em uso Em primeiro lugar: construir para mudança Os requisitos mudam, a tecnologia muda, TUDO muda The purpose of the individual components is clearly important but is in many ways a secondary concern.

O que são componentes?

O que são componentes? Um componente só pode ser utilizado se ele está em conformidade com certos padrões (EJB, COM+)

O que são componentes? É necessário saber o que o componente faz Separar especificação e implementação A especificação é mais importante Componentes podem ser implementados em qualquer linguagem de programação, utilizando qualquer mecanismo de armazenamento de dados

O que são componentes? Enxergamos componentes como um pedaço de software que provê alguns serviços e que requer outros serviços Analogia com empresas Proveem serviços a seus clientes e frequentemente dependem dos serviços de outras empresas Uso de contratos Um contrato é um acordo formal entre duas ou mais partes, descrevendo de forma não ambígua as obrigações de cada parte e as punições caso estas não sejam cumpridas Um contrato não especifica o como será feito, apenas o que tem de ser feito

Uso de contratos com componentes Contrato de uso - como o cliente vai usar o componente Contrato de realização - como o componente deve ser implementado

Camadas da arquitetura do sistema

Processo de desenvolvimento

Processo de desenvolvimento

Definição dos requisitos - Conhecendo o negócio Apesar do levantamento de requisitos ser uma fase importante, não nos preocuparemos com essa etapa Mas uma coisa é certa, os requisitos mudarão Contudo, é essencial conhecer bem o que você irá especificar/implementar Nos preocuparemos com os estregáveis mínimos necessários realizar a especificação dos componentes

Processo de Negócio É fundamental conhecer bem os processos do negócio para o qual a aplicação servirá Todo processo não trivial deve ser documentado A descrição do processo do negócio pode ser feita utilizando-se o diagrama de atividades da UML ou qualquer notação que seja mais familiar à equipe Essa descrição não corresponde aos requisitos do software

Processo de Negócio

Processo de Negócio Exemplo - Locadora de filmes (Como melhorar este diagrama?)

Modelo de Conceitos do Negócio É necessário esclarecer os termos envolvidos no processo Originado (de certa forma) a partir do diagrama anterior Um dos entregáveis necessários para a etapa de especificação dos componentes

Modelo de Conceitos do Negócio

Modelo de Conceitos do Negócio

Casos de Uso Tentativa inicial de atribuir responsabilidades

Casos de Uso Identificar os casos de uso

Casos de Uso Identificar os casos de uso

Casos de Uso

Casos de Uso Exemplo

Especificação dos Componentes

Especificação dos Componentes Identificando os componentes

Especificação dos Componentes Identificando os componentes

Especificação dos Componentes Identificando Interfaces de Sistema Uma interface para cada caso de uso

Especificação dos Componentes Identificando Interfaces de Sistema Uma interface para cada caso de uso

Especificação dos Componentes Identificando Interfaces de Negócio As interfaces de Negócio são identificadas a partir do Modelo de Tipos de Negócio Deve-se seguir os passos: 1. Fazer uma cópia do Modelo de Conceitos do Negócio, esta cópia será o Modelo de Tipos de Negócio 2. Refinar e especificar regras adicionais na forma de restrições 3. Identificar os Tipos Principais 4. Criar uma Interface de Negócio para cada Tipo Principal 5. Refinar o modelo para indicar as responsabilidades de cada interface

Especificação dos Componentes Identificando Interfaces de Negócio Criar o Modelo de Tipos de Negócio como uma cópia refinada do Modelo de Conceitos do Negócio

Especificação dos Componentes Identificando Interfaces de Negócio Adicionar restrições

Especificação dos Componentes Identificando Interfaces de Negócio Identificar os tipos principais

Especificação dos Componentes Identificando Interfaces de Negócio Criar interfaces e atribuir responsabilidades

Especificação dos Componentes Normalmente, um componente para cada interface Exceção quando: Os conceitos representados pelas interfaces possuem o mesmo tempo de vida As interações entre as interfaces são complexas, frequentes ou envolvem grande quantidade de dados É interessante que a substituição dessas interfaces ocorra simultaneamente Deseja-se manter um certo nível de granularidade do sistema

Especificação dos Componentes Componentes de Sistema Componentes de Negócio

Arquitetura inicial dos Componentes

Revisão do Processo