Embed Size (px)
Citation preview
Prof. Sergio Akio Tanaka [email protected]
Pensamento: “Se você esta achando que está no nada... Lembre-se... Que é do nada que se inicia tudo”
Análise e Design Orientado a Objetos com Modelagem WEB utilizando UML
(Unified Modeling Language)
Carga Horária: 60 horas Professor Sergio Akio Tanaka e-mail [email protected]
Parte Ia
Introdução a Orientação a Objetos
Apresentação
• Qual o seu nome? • Formação acadêmica? • Nome da sua empresa e cargo que desempenha? • Qual a sua expectativa com a Disciplina do UML? e a pós como
um todo? • Tem interesse em estar fazendo a certificação oficial de UML? e/
ou outras disciplinas? Experiência prática e acadêmica com UML? OO? Rose? RSM? Outras Ferramentas CASE’s?
Cronograma
• 05 e 06/04/13 – APOO – Sergio Tanaka • 19 e 20/04/13 – APOO – Sergio Tanaka • 26 e 27/04/13 – APOO – Sergio Tanaka • 24 e 25/05/13 - APOO – Sergio Tanaka
Avaliação • 24/05 => Apresentação dos Trabalhos pelas Equipes 1,
2, 3, 4 e 5 respectivamente. • O que será apresentado?
– Site do Projeto (IRUP) • Caso de Desenvolvimento • Modelagem de Negócios (Modelo de UC Negócios e Diagrama de
Objetos de Negócios) • Gerência de Requisitos (Diagrama de Casos de Usos, Protótipo do
Projeto(Interfaces Gráficas), Visão, STR, Especificação dos Casos de Usos, Especificação Suplementar, Glossário e Plano de Gerenciamento de Requisitos)
– Arquitetura do Projeto e Artefato de OOAD (Documento de Arquitetura de Software) - Facultativo
– Diagramas da UML (UC, Atividade, Estado, Sequência, Comunicação, Implantação, Componentes e Classe) e Modelagem UML para a WEB
Forma de Avaliação das Disciplinas:
• Presença em sala de aula • Presença durante a apresentação das outras equipes • Participação nas apresentações • Apresentação individual • Apresentação do grupo • Organização e estruturação do trabalho • Trabalho completo conforme acordado em sala de aula
(artefatos)
EMENTA
• Introduzir conceitos de metodologias para o desenvolvimento de software orientado a objetos, utilizando a UML como linguagem de modelagem do sistema. Estudo de uma metodologia de Análise de Sistemas. Ferramentas de auxílio ao desenvolvimento de Sistemas. Abordar as técnicas para a modelagem de aplicações Web com UML, desde a definição da Arquitetura ao seu Projeto.
Conteúdo Programático • Introdução da Disciplina de OOAD no RUP • Rastreabilidade da Gerência de Requisitos e Modelagem de
Negócios para a disciplina de OOAD • Introdução a Análise de Sistemas
– Paradigmas da Análise – Metodologias de OOAD (Object Oriented Analysis Design)
• Análise e Projeto Orientado a Objetos – Introdução à Orientação a Objetos – Operações e Atributos – Tipo de Objeto e Classes – Agregação e Composição – Estado e Eventos – Generalização e Especialização (herança) – Encapsulamento, Polimorfismo, Comunicação e Estereótipos
Conteúdo Programático • Modelagem Utilizando a UML
– O uso de Pacotes na UML – Diagramas de Casos de Usos – Diagramas de Classes – Diagramas de Seqüência – Diagramas de Colaboração – Diagramas de Estados – Diagramas de Atividades – Diagramas de Componentes – Diagramas de Implantação – Diagramas de Visão Geral – Diagramas de Estrutura Composta – Diagramas de Tempo – Diagramas de Pacotes – Diagrama de Perfil
• O uso de uma ferramenta CASE • Arquitetura 4 + 1
– Aplicações Básicas – Clientes Dinâmicos
• Construções de Aplicações Web • Arquiteturas
– Thin Web Client – Thick Web Client – Web Delivery
• Extensões de Aplicações Web para a UML
Referências 1/2
• OMG. OBJECT MANAGEMENT GROUP. UML 2.0. Disponível em:www.omg.org. 2013.
• Martin. UML Essencial. 3ª Edição. Porto Alegre: Bookman, 2007. • LARMAN, Craig. Utilizando UML e Padrões. 3° Edição. Porto Alegre: Bookman,
2007. • PENDER, Tom. UML 2.0 - A Bíblia. Rio de Janeiro: Editora Campus, 2004. • BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML – Guia do Usuário. 2
ed. Rio de Janeiro: Editora Campus, 2006. • CONALLEN, Jim. Desenvolvendo Aplicações Web com UML. Tradução da Segunda
Edição. Rio de Janeiro: Editora Campus, 2003. • Pressman, Roger S.; Engenharia de Software; Bookman, Porto Alegre, 7 Edição. 2011.
Referências 2/2
• LEFFINGWELL, Dean; WIDRIG, Don. Managing Software Requirements: A Use Case Approach. Boston, MA: Addison-Wesley, 2003. • ERIKSON, Hans-Erik; PENKER, Magnus. Business Modeling with UML: business patterns at work. ISBN: 0-471-29551-5. New York:Wiley, 2000. • IBM. RUP – Rational Unified Process (Software) Versão 7.0. USA: IBM Rational, 2006.
} Objeto } Abstração } Classe } Instância } Atributo } Identificador
} Transição de Estado } Associação } Herança } Encapsulamento } Polimorfismo } Colaboração } Estereótipos
Conceitos Básicos
ê Operação ê Método ê Mensagem ê Evento ê Parâmetro ê Estado
Histórico/Evolução das Linguagens – Surgiu no início da década de 60 – Devido a necessidade dos:
• sistemas de comunicação, fluxo de trânsito, sistemas de produção, sistemas administrativos e sociais.
– Cronograma das Linguagens OO: • 1966 – SIMULA (Kristen Nogaard, Noruega); • 1980 – SMALLTALK (Xerox); • 1986 – C++ (AT&T), SMALLTALK V , OBJECTIVE-C; • 1988 – EIFFEL (Meyer, França); • 1989 – Turbo Pascal 5.5 (Borland); • 1995 – JAVA; • 2001 – C#; • 2002 – VB.NET. • 2013 - .....
Orientação a Objetos
Orientação a Objetos ?
É um paradigma para o desenvolvimento de aplicações, ou seja, é uma estratégia de desenvolvimento de software que organiza o
software como uma coleção de objetos que contém tanto a estrutura dos dados como o comportamento.
Definição
} Características – Forma natural de enxergar a realidade – Forma natural de modelar – Forma natural de codificar
O mundo é Orientado a Objetos
Orientação a Objetos
Propostas da Técnica OO – Reusabilidade:
– de código; – de objetos encapsulados; – Componentes, Frameworks, etc.
– Manutenibilidade: – Mudanças bem localizadas, não acarretando
propagações descontroladas.
– Confiabilidade: – Devido ao encapsulamento, que torna as estruturas de
dados privado aos objetos.
– Extensibilidade – Aumento da Produtividade
Orientação a Objetos
Garantia
Planejamento adequado; Capacitação dos desenvolvedores; Adoção de uma Metodologia e/ou Padrão.
Cronograma das fases de Ciclo de Vida
Garantia de Sucesso
Técnicas de Análise
Apresenta um conjunto de regras e modelos que auxiliam o Engenheiro de Software levantar e modelar os requisitos dos
usuários que o sistema deve atender.
Análise OO
O que é um objeto? • Um objeto é uma entidade com
uma fronteira bem definida e identidade que encapsula o estado e o comportamento – O Estado é representado por
atributos e relacionamentos. – O Comportamento é
representado por operações e máquinas de estados.
Objeto
Operações
Atributos
Princípios Básicos da Orientação a Objetos
Abst
raçã
o
Hier
arqu
ia
Orientação a Objetos
Enca
psul
amen
to
Modu
larid
ade
É o ato de definir um objeto conceitual a partir de OBJETOS do mundo real que possuam as mesmas características e
comportamento, podendo ser classificados como pertencentes a um mesmo tipo.
Dinheiro
Abstração
Representa a abstração de um conjunto de OBJETOS do Mundo Real que possuem tipos de características e de comportamento em
comum.
Pessoa
Classe
Exemplo
Funcionários Ana, João, Fátima, Pedro, Carlos.
Classe Funcionário possui nome possui endereço possui data de nascimento possui telefone
Classe
Representa cada ocorrência de um OBJETO formados a partir de uma CLASSE.
Funcionário 1 Ana 2 João 3 Fátima 4 Pedro 5 Carlos
Instância
Objeto Funcionário 2 (instância) Ana Maria Av. Curitiba, 444 05/02/69 999-9999
Exemplo
Classe Funcionário possui nome possui endereço possui data de nascimento possui telefone
Objeto Funcionário 1 (instância) Carlos Av. Curitiba, 44 05/03/69 999-9998
Instanciação
Instância
É uma característica particular possuída por todos os OBJETOS de uma CLASSE e assume valores específicos
para cada OBJETO.
Classe Funcionário (possui) CPF (possui) RG (possui) Nome (possui) Endereço
Atributo
Exemplo
Valor: nome = João, endereço = rua ..... , data de nascimento = 05/07/71
telefone = 999-9999
Classe Funcionário (possui) nome (possui) endereço (possui) data de nascimento (possui) telefone
Atributo
Identificador Único
É um ou vários ATRIBUTOS, cuja função é permitir a individualização de cada INSTÂNCIA.
IDPessoa
Identificador Único
Exemplo Classe Funcionário
Funcionario-ID RG Nome Endereço Data Nascimento
Operação
Um serviço que é requisitado a um objeto como parte de seu comportamento em resposta a estímulos. Uma
operação tem uma assinatura que pode restringir quais parâmetros reais são possíveis.
Operação
É o que os Objetos de uma Classe sabem realizar.
Cafeteira.esquenta
Cafeteira.aumentaTemperatura
Cafeteira.diminuiTempo
Operação Exemplo
Funcionário Fala Corre Anda Come
Lê
Funcionário Cria()
Elimina() Recupera() Atualiza()
Métodos CERA
Método
Exemplo da implementação de um método em JAVA:
void remover(ActionEvent e) {
try {
deleteRow(); saveChanges(); }
catch (Exception ex) {
desabilita(); }
}
Mensagem
Representa o mecanismo de invocação de uma OPERAÇÃO.
É o mecanismo utilizado para solicitar uma OPERAÇÃO. É a forma de conseguir executar uma OPERAÇÃO.
Operação Abrir
Evento ao abrir mensagem
Evento
Um evento é uma especificação de uma ocorrência significativa que tem uma localização no
tempo e no espaço.
Evento Ao abrir
Parâmetro
Representa um ou mais ATRIBUTOS carregados dentro de uma MENSAGEM.
Pessoa.elimina (CPF)
Estado Um estado é uma condição ou situação na vida de um objeto durante a qual ele satisfaz a alguma condição,
realiza alguma atividade ou aguarda algum evento.
Evento Ao abrir
Estado Fechado Estado Aberto
Estado
Exemplo
Classe Exemplar ISBN Nº Tombo ... estado
Criado Eliminado Emprestado Em manutenção Reservado Liberado
Transição de Estado Uma transição é um relacionamento entre dois estados,
indicando que um objeto no primeiro estado realizará certas ações e entrará no segundo estado quando um evento
especificado ocorrer e as condições especificadas estão satisfeitas.
Estado Fechado Estado Aberto
Estado Criado Estado
Eliminado
Associação
Representa a forma como os OBJETOS de uma mesma CLASSE ou de CLASSES diferentes se
reconhecem entre si.
BANCO AGÊNCIA Possui 1 *
Exemplo de Hierarquia
Diminuição da Abstração
Aumento da abstração
Asset
RealEstate
Savings
BankAccount
Checking Stock
Security
Bond
Elementos do mesmo nível de hierarquia deveriam estar no mesmo nível de abstração.
Herança
Representa a propriedade pela qual uma CLASSE pode herdar características e comportamento de uma outra CLASSE.
Pessoas
Pessoas{abstract} Nome Endereço Telefone Cria() {abstract} Elimina() {abstract} Recupera() {abstract} Atualiza() {abstract}
Fornecedor CNPJ Cria() Elimina() Recupera() Atualiza()
Cliente CPF Cria() Elimina() Recupera() Atualiza()
Operações abstratas
Operações Concretas
Herança
Exemplo de Herança Múltipla
Veículo
Veículoterrestre
Veículoaquático
Veículoanfíbio
{sobreposição, incompleto}
Ilustração de Encapsulamento • Professor Kenji necessita
estar disponível para ministrar aulas para as quatro turmas no próximo semestre.
TakeSabbatical()
Professor Kenji
Name: S. Kenji Employee ID: 567138
HireDate: 07/25/1991
Status: Tenured
Discipline: Finance
MaxLoad: 4 SetMaxLoad(4)
“Encapsulamento: significa separar o programa em partes, o mais isoladas possível. A idéia é tornar o software mais flexível, fácil de modificar e de criar novas implementações”.
Exemplo de Modularidade • Por exemplo, quebrar um
sistema complexo em pequenos módulos. Sistema de
Pagamento
Sistema de Registro de Curso
Sistema de catálogo de curso
Sistema de gerenciamento de estudantes
Polimorfismo
Representa a propriedade pela qual OBJETOS de CLASSES diferentes possuem tipos de reações
particulares a uma mesma operação.
Uma mesma operação pode se comportar de diferentes formas sobre diferentes CLASSES.
A Mensagem é a mesma. A reação é diferente para cada tipo de
Objeto.
Mundo Natural
Polimorfismo
Exemplo Funcionário Livro
Operação Criar Exemplar Banco Agência
... a estrutura (atributos) de cada classe é diferente
Polimorfismo
Colaboração
É a troca de MENSAGENS entre OBJETOS. É uma
comunicação entre OBJETOS e Atores.
Estereótipos => UML 1.x Palavras Chaves => UML 2.0
} Sugerido por Rebecca Wirfs-Brock em 1990;
} Torna a UML extensível pelo usuário do método pela definição de estereótipos adicionais;
} O uso do estereótipo é omitido quando a semântica predefinida na UML for suficiente;
} Um estereótipo é escrito textualmente (em guillmets sobre a seqüência de nome);
} Ex: <<estereótipo>>.
Análise e Design Orientado a Objetos com Modelagem WEB utilizando UML
(Unified Modeling Language)
Professor Sergio Akio Tanaka e-mail [email protected]
Parte Ib Introdução a UML
Apresentação da UML
UML, Linguagem formada pela junção das melhores técnicas de modelagem (OMG 2008).
UML, Linguagem de Modelagem Unificada, é uma linguagem gráfica para visualização, especificação,
construção e documentação de artefatos de sistemas complexos de software (BOOCH 2006).
Inputs to the UML
Fusion Operation descriptions, message numbering
Before and after conditions
Meyer
Harel State charts
Wirfs-Brock Responsibilities
Embley
Singleton classes, High-level view
Odell Classification Object lifecycles
Shlaer- Mellor
Gamma, et.al Frameworks, patterns, notes
Booch Rumbaugh Jacobson
Selic, Gullekson, Ward
ROOM (Real-Time Object-Oriented Modeling)
Breve Histórico (UML) • Oficialmente em Out/94 Rumbaugh se junta a Booch na Rational; • Foco inicial do projeto era a unificação dos métodos Booch e OMT; • Out/95 lançado um esboço da versão 0.8; • Jun/96 lançado a versão 0.9 incorporando o método OOSE de Jacobson; • Jan/97 v.1.0 oferecida para padronização a OMG (Object Management Group); • Versão revisada 1.1, oferecida para padronização a OMG Julho/97; • 14 de Novembro de 1997 a UML é aprovada pela OMG (v.1.1); • Revisão da UML assumida pela RTF (Revision Task Force) do OMG, lançando
a versão 1.2 em junho 1998; • Dez/98 a RTF lança a versão 1.3; • 15/9/2000, a OMG estendeu o prazo p/ a aprovação da UML 1.4 p/ 22/12/2000; • UML 1.5, combinação da UML 1.4 • 15/09/2000 UML 2.0 definida pelo Working Group. • 2004 – Consolidação da UML 2.0, 2.1, 2.2, 2.3 E 2.4 • 2013 – Continuação da UML 2.x….
Histórico UML (Forma gráfica)
UML Partners’ Expertise
UML 1.0 (Jan. ‘97)
UML 1.1 (Sept. ‘97)
UML 1.5 (March, ‘03)
UML 2.0 (2004)
Other Methods
Booch ‘91 OMT - 1 OOSE
Booch ’93 OMT - 2
Public Feedback Unified Method 0.8
(OOPSLA ’95)
UML 0.9 (June ‘96)
UML 0.91 (Oct. ‘96)
and
E finalmente o histórico real da ...UML... Ilustração de como foi extraída a UML no laboratório da
Rational
Tipos de Modelagem - V. 1.x • Modelagem Estrutural
– 1-Diagrama de Classes – Diagramas de Pacotes; => oficializado como diagrama na versão 2.0 – Diagramas de Objetos. => oficializado como diagrama na versão 2.0
• Modelagem Comportamental – 2-Diagramas de Casos de Uso; – 3-Diagramas de Seqüência; – 4-Diagramas de Colaboração; => diagrama de comunicação na versão 2.0 – 5-Diagramas de Atividades; – 6-Diagramas de Estados; – Processos e Threads; – Eventos e Sinais.
• Modelagem Arquitetural – 7-Diagramas de Componentes; – 8-Diagramas de Implantação; – Patterns e Frameworks.
Tipos de Modelagem - V. 2.4 Na versão 2.4, a UML tem quatorze diagramas divididos em:
Modelos
Dynamic Diagrams
w Multiplas visões
Activity Diagrams
Models
Static Diagrams
Sequence Diagrams
Communication Diagrams
State Machine Diagrams
Deployment Diagrams
Component Diagrams
Object Diagrams
Class Diagrams Use-Case
Diagrams
Dinâmico
Iniciando a Modelagem e Rastreabilidade entre os elementos
Antes, vamos fazer uma Revisão dos conceitos
básicos do RUP. Revisar, também, a Modelagem de Negócios e Gerência de
Requisitos em relação a disciplina de Análise e Design
Melhores Práticas
} Aplicando as 6 melhores práticas:
} Desenvolvimento Iterativo } Gerência de Requisitos } Uso da Arquitetura de Componentes } Modelo Visual (UML) } Verificação Contínua da Qualidade } Gerência de Mudanças
PRO
CESSO
CO
NFIG
UR
ÁVEL
Princípios Chave para o Desenvolvimento Orientado a Negócios
– Adaptar o Processo
– Equilíbrio que compete as Prioridades dos Stakeholders
– Colaboração Entre os Times
– Demonstrar o Valor Iterativamente
– Elevar o Nível de Abstração
– Focar Continuamente na Qualidade
Modelo de Objetos de Negócio
} Define o ponto de vista dos trabalhadores de negócio ponto de vista interno.
Modelo de Negócio e Atores de Sistema
ATOR Caso de Uso
“Breve Revisão”- Diagrama de Casos de Uso
Elementos e Notação:
Representa o estudo e modelagem da interface externa do sistema.
Descrição dos requerimentos dos usuários.
Ator
“ATOR” é qualquer pessoa, departamento, sistema computacional e dispositivos que utilizam funcionalidades do
Sistema.
Caso de Uso
“Representa qualquer interação de serviços entre um ATOR e o SISTEMA. Cada serviço é representado como um Caso
de Uso (Use Case)”.
SISTEMA
Diagrama de Casos de Uso
OBSERVAÇÕES: Não representar para o mesmo ATOR mais do que uma missão.
Departamento e sistema pessoal
Departamento pessoal
Sistema pessoal
Casos de Uso – Nível de Especificação
• Definir Funcionalidades Genéricas; • Regras de Negócios; • Visão do Usuário;
O Escopo de um Caso de Uso
Geralmente, é difícil decidir se um conjunto de interações do usuário do sistema (ATOR COM O SISTEMA), ou uma caixa de diálogo, é um ou são vários casos de uso. Considere o uso de uma máquina de reciclagem. O cliente insere itens de depósito como, por exemplo, latas, garrafas e caixotes na máquina de reciclagem. Ao inserir todos os itens de depósito, basta pressionar um botão e um recibo é impresso. Esse recibo pode ser trocado por dinheiro.
Cada Comunicação-Associação é um conjunto de diálogo
Estudante Sistema de Catálogo de
Cursos
Registrar Cursos
Estudante faz o login no sistema Sistema aprova o login Estudante solicitação informação do Curso
Sistema mostra a lista de cursos Estudante seleciona cursos Sistema confirma curso disponível Sistema mostra aprovação da programação
Sistema transmite solicitação Catálogo de Cursos retorna informação do curso
Herança entre atores } Pode-se utilizar herança entre atores;
} Herança entre atores significa que um ator preenche os mesmos papéis de outro ator, podendo também preencher papéis adicionais;
} Na UML herança é indicado pelo relacionamento de generalização.
Herança entre atores
Ator 1
Ator 2
Caso de Uso 2
Caso de Uso 3
Caso de Uso 1
Ator 3
Created with Visio
Relacionamentos Entre Casos de Uso
<<extend>>
<<include>>
• Include
• Extend
• Generalização
O que é um Relacionamento Include?
• Um relacionamento de um caso de uso base para um caso de uso de inclusão
• O comportamento definido no caso de uso de inclusão é inserida explicitamente para o caso de uso base
<<include>>
Base
Inclusão
Relacionamento Include: Exemplo RU e-st
Obter Cota
Executar Comércio
Outros UC
Identificar Cliente
<<include>>
<<include>>
<<include>>
Caso de Uso Obter Cota 1. Incluir “Identificar Cliente” para verificar identidade do cliente 2. Mostrar opções. Cliente seleciona “Obter Cota” 3. ...
Caso de Uso Identificar Cliente 1. Logon 2. Validar logon 3. Entrar com a senha 4. Verificar a senha A1: Logon inválido A2: Senha errada A3: .....
Por Que Usar um Relacionamento de Include?
• Fatorar comportamento comum para dois ou mais casos de uso – Evitar descrever qualquer comportamento
múltiplas vezes (reutilização). – Assegurar comportamento comum consistente
com o resto. • Fatorar e encapsular comportamento de um caso de
uso base – Simplificar fluxo de eventos complexos (ver
exemplo RU-st) – Fatorar comportamento que não faz parte de um
propósito primário.
<<include>>
Base
Inclusão
O que é um Relacionamento Extend?
• Conexão de um caso de uso estendido para um caso de uso base – Inserir comportamento estendido de um caso de uso num caso de
uso base – Inserir somente se a condição de extensão for verdadeira – Inserir num caso de uso base ao ponto de extensão nomeado
<<extend>>
Extensão
Base
Relacionamento Extend: Exemplo RU e-st
Sistema News
Sistema Especialista
de Cota
<<extend>> <<extend>> Cliente do Comércio
Obter Cota
Obter News Obter Prognóstico
Relacionamento Extend: Exemplo RU e-st (cont.)
Caso de Uso Obter Cota Fluxo Básico 1. Include “Identificar Cliente” para verificar identidade do cliente. 2. Mostrar opções 3. Cliente seleciona “Obter Cota.” 4. Cliente obtém cotas 5. Cliente obtém outras cotas 6. Cliente faz logoff A1. Sistema Cota indisponível ... Pontos de Extensão: O ponto de extensão “Serviço Opcional” ocorre no Passo 3 do Fluxo Básico.
Caso de Uso Obter News Este caso de uso extend o Caso de Uso Obter Cota, ao ponto de extensão “Serviços Opcionais”. Fluxo Básico: 1. Se o Cliente selecionar “Obter News”, o sistema pergunta ao cliente o período de tempo e o número de itens news. 2. Cliente entra com o período de tempo e o número de itens. O sistema envia o símbolo da ação de comércio para o Sistema News, recebe resposta, e mostra os news para o cliente. 3. O Caso de Uso Obter Cota continua. A1: Sistema News Indisponível A2: Não Existe News Sobre Esta Ação
Execução de um Extend • Executado quando o ponto de extensão é alcançado e a
condição de extensão (decisão) for verdadeira
Caso de Uso Base Instância do Caso de Uso
Ponto de Extensão
Caso de Uso Extensão
Por Que Usar um Relacionamento Extend?
• Fatorar um comportamento opcional ou excepcional – Executado somente numa certa condição – Fatorando a simplificação do fluxo de eventos do
caso de uso base – Exemplo: ligando um alarme
• Adicionar comportamento estendido – Desenvolver comportamento separadamente,
possivelmente numa versão posterior – Exemplo: Caso de Uso Obter News
<<extend>>
Extensão
Base
Casos deUso (Concreto versus Abstrato)
Um caso de uso é abstrato ou
concreto
Casos de uso concreto (B & C): - Deve ser completo e significativo - Pode ser instanciado para si mesmo
Casos de uso abstrato (A & D): - Não tem que ser completo. - Existe somente por outros casos de uso. - Nunca são instanciados para si mesmo (não é inicializado por um ator).
A
B
C
D
<<include>>
<<extend>>
É comum o caso de uso de extensão ser abstrato, mas não é necessário que seja.
Exemplo de um diagrama de Caso de Uso para um Sistema
de Controle de Estágio
Universidade
(from Actors)
Firmar Convênio(f rom Firmar Conv ênio)
Empresa
(from Actors)
Definir Empresa para desenvolvimento
(f rom Defini r Empresa para desenv olv imento)
Definir Professor Orientador
(f rom Definir Prof essor Orientador)
Coordenador Estágio(from Act...
Definir Aluno(f rom Def inir Aluno)
Avaliar Aluno(f rom Av aliar Aluno)
Professor Orientador
(from Actors)
Registrar Plano de Estágio(f rom Registrar Plano de Estagio)
Efetuar Controle de Estágio
(f rom Ef etuar Controle de Estágio)
Registrar entrega da RPOD
(f rom Registrar entrega da RPOD)
Aluno
(from Actors)
Diagramas de Casos de Uso 1.
Fazer o levantamento
com os usuários para identificar os Atores e os Casos de Uso.
2. Fazer uma
lista dos possíveis Atores.
3. Filtrar a
lista e definir os Atores.
4. Fazer uma
lista dos possíveis Casos de
Uso dos Atores.
5. Filtrar e
definir os Casos de Uso para cada Ator.
6. Representar
cada Ator com seus Casos de Uso
no diagrama.
7. Realizar
levantamento junto aos usuários
para entender como o
sistema deve atender os
Casos de Uso.
Análise e Design Orientado a Objetos com Modelagem WEB utilizando UML
(Unified Modeling Language)
Professor Sergio Akio Tanaka e-mail [email protected]
Parte Ic
Introdução a Arquitetura de Software
Pacote
• Um pacote é um mecanismo de propósito geral para a organização de elementos em grupos. Um pacote é representado graficamente como uma pasta com uma guia.
Pacote • Cada pacote deve ser nomeado;
• O nome dos pacotes são escritos sobre os pacotes; • Ligações entre os pacotes são representadas para indicar a
dependência entre os pacotes;
u Notação: Pacote1 Nome
Dependência de Pacotes
u Notação de Dependência:
Pacote1 Pacote2Pacote1 Nome
Pacote1 Nome
Pacote2 Nome
Relacionamento de dependência
Contexto em Análise Arquitetural [Early
Elaboration Iteration]
[Inception Iteration (Optional)]
Define a Candidate Architecture
Perform Architectural
Synthesis
Analyze Behavior
Refine the Architecture
Design Components
Design the Database
(Optional)
Architecture Analysis
Architect
Visão Geral da Análise Arquitetural
Supplementary Specification
Glossary
Use-Case Model
Architectural Analysis
Design Model
Reference Architecture
Deployment Model
Vision Document
Software Architecture Doc
Project-Specific Guidelines
Papel: Arquiteto de Software
• O papel arquiteto de software lidera e coordena as atividades e os artefatos técnicos no decorrer do projeto. O arquiteto de software estabelece a estrutura geral de cada visão de arquitetura: a decomposição da visão, o agrupamento dos elementos e as interfaces entre esses principais agrupamentos. Portanto, comparado aos outros papéis, a visão do arquiteto de software é ampla, e não detalhada.
Qual o conhecimento de um Arquiteto de Software?
• "O arquiteto ideal deve ser uma pessoa erudita, um matemático, familiarizado com estudos históricos, um estudioso aplicado de filosofia, conhecedor de música, que não desconheça medicina, detentor de saber jurídico e familiarizado com astronomia e cálculos astronômicos." - Vitruvius, há aproximadamente 25 anos a.C.
Arquitetura de Software
Segundo Buschmann 1996, a arquitetura de software consiste da descrição dos subsistemas, e dos componentes de um sistema de software e dos relacionamentos entre eles.
Subsistemas,
Componentes
Arquitetura 4 + 1
Process View Deployment View
Logical View
Use-Case View
Implementation View
Usuário-final Funcionalidade Programador
Gerência de Software
Performance Escalabilidade Rendimento
System integrators Topologia do Sistema
Entrega, instalação comunicação
System engineering
Analista/Projetista Estrutura
Pacotes (Importação e Exportação) } Na UML, a modelagem de um relacionamento de importação
é feita como uma dependência assinalada pelo estereótipo <<import>> como adorno;
} As partes públicas de um pacote são chamadas suas exportações;
} As partes exportadas por um pacote são visíveis somente para o conteúdo dos pacotes que importam aquele pacote explicitamente.
} As dependências de importação e de acesso não são transitivas.
Pacotes
} Dois ou três níveis de aninhamento constituem o limite do
que será conveniente utilizar. Mais do que o aninhamento,
utilize a importação para a organização de seus pacotes.
Pacotes A UML define 5 estereótipos-padrão que se aplicam aos pacotes:
– <<facade>>: especifica um pacote que é apenas uma visualização de algum outro pacote;
– <<framework>>: especifica um pacote que é formado por padrões;
– <<stub>>: serve como proxy para o conteúdo público de outro pacote; ou seja, são utilizados quando possuimos ferramentas capazes de dividir um sistema em pacotes que manipulamos em diferentes momentos e potencialmente em diferentes locais.
– <<subsystem>>: representa uma parte independente de todo o sistema cuja modelagem está sendo feita.
– <<system>>: representa todo o sistema cuja modelagem está sendo feita.
A
B
X
Acoplamento de Pacotes
• Acoplamento: quanto maior a dependência entre os pacotes maior o acoplamento
• Pacotes não deveriam ter co-dependências (circular)
• Pacotes da camada inferior não deveria ser dependente da camada superior. Isto é uma regra para o estilo arquitetural em camadas
• Em geral, as dependências não deveriam pular camadas
A B
Upper Layer
Lower Layer
C
X
X = Violação de acoplamento
X
Exemplo: Arquitetura em Camadas
Middleware <<layer>>
Base Reuse
global
Application <<layer>>
Business Services
<<layer>>
Necessary because the Application Layer must have access to the core distribution mechanisms provided with Java RMI.
C
A
B
A Hierarquia deveria ser aciclica
Dependências Circulares torna dificil o reuso para reutilizar um pacote sem o outro. Solução no exemplo, acima, criar um novo pacote A” que seja comum para
A e C.
Evitando Dependências Circulares
A
B
A
B
C
A'
Estilo Arquitetural
Um estilo de arquitetura pode ser definido como uma família de sistemas em termos de um modelo de estrutura de organização. Um estilo de arquitetura expressa componentes e o relacionamento entre eles, com restrições de suas aplicações, composições e regras de projeto para suas construções [BUS 96]. Mais especificamente, pode-se dizer que um estilo de arquitetura define um vocabulário de componentes e tipos de conectores, mais um conjunto de restrições sobre a combinação desses (GARLAN 1995).
Arquitetura de Software Tipos de estilos arquiteturais: ü Pipes e Filtros
ü Camadas
ü Objetos
ü Invocação Implícita
ü Quadro-negro
ü Repositório (Passivo)
ü Arquiteturas de Aplicações Distribuídas
ü Processos Comunicantes
ü Cliente-Servidor
ü Chamada de Procedimento
Exercício 1:
• Configurar na Ferramenta CASE IBM Rational Rose para a visualização da Arquitetura Multicamadas
• Elaborar o Estilo Arquitetural proposto para utilização nos estudos de casos utilizando pacotes
Arquitetura de Software
Proposta do Estilo Arquitetural em Camadas para o desenvolvimento dos estudos de casos
CV Resumido do Professor
SERGIO AKIO TANAKA, MSc Área • ENGENHARIA DE SOFTWARE, ARQUITETURA CORPORATIVA
GERÊNCIA DE PROJETOS E PROCESSOS DE NEGÓCIOS
Sergio Akio Tanaka, atua na área de Informática desde 1990 tanto na área acadêmica como empresarial. É Especialista em Gestão Empresarial pelo ISE - Instituto Superior de Ensino em convênio com o IESE de Barcelona. Mestre em Ciência da Computação pela Universidade Federal do Rio Grande do Sul; Pós-graduado pela Universidade Estadual de Londrina nas áreas de Redes de Computadores e Banco de Dados e em Análise de Sistemas pela UniFil; Graduado em Processamento de Dados. Engenheiro de Software certificado pela IBM Rational em diversas áreas. Ao Longo da sua carreira, foi Diretor de Novas Tecnologias da K2Solutions. Atuou como Gerente Geral da PLATIN/ADETEC e Consultor do Agente Softex/ADETEC no mercado Espanhol, Instrutor e Coordenador da área de TI do SENAC por 11 anos e foi Gerente da KAIZEN - DATABASE Marketing por 5 anos. Atualmente, é Diretor Geral, e também, consultor certificado pela IBM Rational na AUDARE Engenharia de Software. Na área acadêmica, desde 1994, atua como professor e coordenador da UNIFIL - Universidade Filadélfia nos cursos de Pós-Graduação da área de Computação e Pesquisa, Professor e Coordenador de Pós-Graduação na área de Engenharia de Software do SENAI/SC e SENAI-PR; Professor Ad-hoc da UNIVEL, UNIVALE, UNOPAR, UNIPAR e UEL em cursos de Pós-graduação. Possui expertise em Gerência de Projetos, Arquitetura de Software, UML, Construção de Frameworks e Componentes, Processo de Desenvolvimento de Software, Gerência de Requisitos, Gerência de Mudanças, Workflow, Modelagem Web e de Negócios. Possui forte experiência no mercado Internacional e Possui mais de 100 artigos publicados (veja plataforma lattes).
![[UML] UML, Metodologias e Ferramentas CASE us](https://img.document.onl/doc/110x75/5571f34149795947648dbd59/uml-uml-metodologias-e-ferramentas-case-us.jpg)
