FACULDADE DO LITORAL SUL PAULISTA FALS MARCOS ANTONIO FERIAN FILHO SISTEMA DE GERENCIAMENTO DE VENDA UML

Transcrição

1 FACULDADE DO LITORAL SUL PAULISTA FALS MARCOS ANTONIO FERIAN FILHO SISTEMA DE GERENCIAMENTO DE VENDA UML PRAIA GRANDE 2010

2 MARCOS ANTONIO FERIAN FILHO SISTEMA DE GERENCIAMENTO DE VENDA UML Projeto de Matéria de Trabalho de conclusão de curso, Faculdade do Litoral Sul Paulista, sob orientação do Prof. Paulo R. T. Cândido. PRAIA GRANDE 2010

3 MARCOS ANTONIO FERIAN FILHO SISTEMA DE GERENCIAMENTO DE VENDA UML Projeto de Matéria de Trabalho de conclusão de curso, Faculdade do Litoral Sul Paulista, sob orientação do Prof. Paulo R. T. Cândido. AVALIAÇÃO: NOTA: ( ) PRAIA GRANDE 2010

4 RESUMO É de extrema importância utilizar uma metodologia de desenvolvimento de sistema para obtermos, desde os primeiros passos, até a etapa final de conclusão do projeto de software. Citamos a UML por ser a unificação das três mais conceituadas linguagens de modelagem de sistemas orientadas a objetos (Booch de Grady, OOSE de Jacobson e o OMT de Rumbaugh). Este trabalho mostra a utilização da UML no sistema para que se possa criar uma metodologia de desenvolvimento do sistema que englobe todas as fases do projeto, desde os eventos iniciais, passando pelo levantamento de Requisitos, Análise, Projeto, Programação e Testes. PALAVRAS CHAVES: metodologia, desenvolvimento, UML, Programação.

5 5 ABSTRACT It is extremely important to use a system development methodology to obtain, from the early stage until the final stage of completing the software project. We quote the UML to be the unification of the three most prestigious modeling languages for object-oriented systems (Grady Booch, OMT and Jacobson's OOSE of Rumbaugh). This work shows the use of UML in the system so you can create a system development methodology that encompasses all phases of a project from the initial events, going from Olympic Requirements, Analysis, Design, Programming and Testing. KEY WORDS: methodology, development, UML, Programming

6 6 SUMÁRIO 1 INTRODUÇÃO... Erro! Indicador não definido. 1.1 APRESENTAÇÃO OBJETIVOS GERAIS E ESPECÍFICOS JUSTIFICATIVA ABRANGÊNCIA METODOLOGIA ESTRUTURA ANÁLISE E PROJETOS ORIENTADOS A OBJETOS CONCEITOS E HISTÓRIA ANÁLISE ORIENTADA A OBJETOS O PROJETO ORIENTADO A OBJETOS CLASSES OBJETOS ABSTRAÇÃO Abstração de procedimentos Abstração de dados ENCAPSULAMENTO HERANÇA POLIMORFISMO UML INTRODUÇÃO HISTÓRICO COMPLETO ACEITAÇÃO PADRONIZAÇÃO OMG APLICAÇÃO DA UML ETAPAS DE DESENVOLVIMENTO DE UM SISTEMA UTILIZANDO UML ANÁLISE DE REQUISITOS ANÁLISE PROJETO PROGRAMAÇÃO...25

7 7 4.5 TESTES MODELOS DE ELEMENTOS DEFINIÇÃO RELEMBRANDO CLASSES Nomes Relembrando atributos OPERAÇÕES Relembrando objetos ESTADOS PACOTES COMPONENTES RELACIONAMENTOS ASSOCIAÇÕES Agregação Generalizações Generalização normal Generalização restrita DEPENDÊNCIA E REFINAMENTOS MECANISMOS GERAIS DIAGRAMAS CONCEITOS Diagrama de Casos de Uso DIAGRAMA DE CLASSES DIAGRAMA DE OBJETOS DIAGRAMA DE ESTADOS DIAGRAMA DE SEQUÊNCIA DIAGRAMA DE COLABORAÇÃO DIAGRAMA DE ATIVIDADES DIAGRAMA DE COMPONENTES DIAGRAMA DE IMPLANTAÇÃO CONCLUSÃO REFERÊNCIAS BIBLIOGRÁFICAS Referencial Eletrônico... 55

8 8 1 INTRODUÇÃO 1.1 APRESENTAÇÃO Os desenvolvimentos do sistema de software de grande porte são suportados por métodos de análise e projeto que modelam esse sistema de modo a fornecer para todos os envolvidos (cliente, analista, programador, etc) uma compreensão única do projeto. A UML não é uma metodologia de desenvolvimento, o que significa que ela não diz pra você o que fazer primeiro, qual passo inicial ou como projetar seu sistema, mas ela auxilia na visualização dele como um todo e a comunicação entre os objetos. A UML traz novos conceitos que geralmente não são usados, um bom entendimento dessa linguagem não é somente um conhecimento básico de sua simbologia e significado, mas também um contexto geral de modelagem orientada a objetos. Com a junção das três mais conceituadas metodologia de modelagem orientada a objetos criou-se a UML, aproveitando o que havia de melhor em cada um delas, adicionando conceitos e visões da linguagem. UML permite criar certos conceitos mais claramente que as linguagens alternativas (Fowler, 2000). Para entendermos melhor, conceituamos UML como uma padronização de modelagem orientada a objetos, de forma que qualquer sistema possa ser modelado corretamente, com consistência, fácil de ser entendido, atualizado e compreensível. Com este trabalho, pretendo justamente, pesquisar sobre esta linguagem de modelagem, suas aplicações, vantagens e desvantagens.

9 9 1.2 OBJETIVOS GERAIS E ESPECÍFICOS Objetivamos de maneira geral com esta pesquisa, o estudo aprofundado de uma metodologia de modelagem unificada de desenvolvimento de sistemas orientados a objetos baseados em UML e sua utilização para melhor entendimento graficamente representado, o nosso sistema de carimbos. Claramente, os objetivos apresentados são: Aprofundar nosso estudo sobre UML, obtendo um amplo conhecimento sobre essa metodologia; Estudar como se desenvolve uma metodologia de desenvolvimento de Sistemas; Mostrar a importância do uso da metodologia no desenvolvimento de Sistemas; Desenvolver uma metodologia de trabalho baseada em UML; Mostrar as grandes vantagens da UML utilizando como estudo de caso situações rotineiras do nosso sistema;

10 JUSTIFICATIVA Com o interesse em estudar uma metodologia unificada de desenvolvimento baseada no nosso sistema, desenvolvemos o presente projeto com o intuito de apresentar uma metodologia e salientar a importância da sua aplicação, a qual nos ajuda resolver muitos problemas encontrados no decorrer de todo o desenvolvimento de um sistema. 1.4 ABRANGÊNCIA A UML é uma linguagem de desenvolvimento de sistemas orientados a objetos dominantes, comuns entre os melhores analistas e desenvolvedores. Pretendemos comprovar a eficácia do uso desta metodologia. Pontos a serem citados: A Modelagem de Sistema, usando os conceitos da orientação a objetos; Estabelecer um método conceitual entre toda equipe envolvida no projeto do sistema (cliente, analista, desenvolvedor, etc) Mostrar a qualidade de um sistema desenvolvido utilizando UML. 1.5 METODOLOGIA Para organizarmos melhor o trabalho, vamos definir as seguintes etapas: Estudo da Metodologia UML; Conceitos sobre esta metodologia; Utilização da metodologia estudada com base no nosso sistema de carimbos; Estudo e definição de ferramentas para desenvolvimento de sistemas; Conclusão sobre a metodologia utilizada e sua aplicação;

11 ESTRUTURA Este tópico falará um pouco do nosso trabalho e no que constitui cada capítulo. No capítulo 2, descreveremos um pouco da análise de projetos orientados a objetos, necessidades, surgimento, utilização, etc. Esse capítulo é extremamente importante para o entendimento da análise orientada a objetos. No capítulo 3, faremos a introdução a UML (Unified Modeling Language ou Linguagem de Modelagem Unificada), citaremos sua utilização, o que ela nos disponibiliza, aceitação, padronização, documentação, atualização e aplicações. No capítulo 4, falaremos um pouco das etapas técnicas da UML, essas etapas vão desde o levantamento dos requisitos até, praticamente, o fim do projeto, que é a fase de testes. O capítulo 5 traz uma definição de modelos de elementos e descreve detalhadamente todos os modelos de elementos utilizados pela UML. O capítulo 6 fala um pouco sobre os diagramas de UML, mostra um pouco dos 9 tipos de diagramas utilizados pela UML, exemplificando graficamente e simulando o uso de alguns destes diagramas. Neste capítulo também, você poderá ver, o uso de dois destes diagramas com teste em diversos cenários no nosso sistema. No capítulo 7 faremos as conclusões finais sobre todo o trabalho. O capítulo 8 traz toda a bibliografia utilizada no desenvolvimento do trabalho.

12 12 2 ANÁLISE E PROJETOS ORIENTADOS A OBJETOS 2.1 CONCEITOS E HISTÓRIA Como vimos, a importância da modelagem dentro de um sistema é indiscutível, ela é a parte central que leva a todas s informações para a implantação de um bom sistema. Com ela, podemos visualizar e controlar o desenvolvimento de um sistema de maneira eficaz, identificando e gerenciando riscos, estipulando e cumprindo prazos, dentro das estimativas de custo. Tendo como base essas informações iniciais, várias metodologias para o desenvolvimento de sistemas foram criadas. As primeiras, que foram as metodologias estruturadas, caracterizam o desenvolvimento de um sistema em torno de procedimentos e funções. Até os dias de hoje, existem sistemas ainda desenvolvidos com base em metodologias estruturadas, o que os torna pouco estáveis, pelo fato de que, à medida que os requisitos vão se modificando com o crescimento da empresa, a manutenção do sistema, necessária, fica cada vez mais difícil. Com a evolução das metodologias, o desenvolvimento de sistemas passou a ter uma visão diferenciada, com outras perspectivas. Foi nesse momento, que surgiu as metodologias orientadas a objetos, que caracterizam o escopo do desenvolvimento do sistema em torno de classes e objetos. Essa metodologia foi muito bem aceita no mundo dos desenvolvedores, tendo em vista, que o método orientado a objetos possibilitava a construção de projetos de sistemas de todos os tipos de domínio e problema, incluindo todos os graus de tamanho e complexibilidade. O sucesso da modelagem orientada a objetos foi tão grande, que em pouco tempo, foram surgindo muitos e muitos métodos, e esse crescimento deu-se de maneira desordenada em um curto espaço de tempo. Eram inúmeros métodos, cada um com suas peculiaridades e falhas, e sem nenhum relacionamento com os demais. Sendo assim, os usuários destes métodos, sentiram a dificuldade de encontrar um, que atendesse todas as suas expectativas, o que ocasionou a chamada guerra de métodos.

13 13 Como toda guerra sempre tem um vencedor, nos métodos não foi diferente. Tendo os métodos de maior destaque dentre todos, méritos de Jacobson, Booch e Rumbaugh, surgiu a linguagem de modelagem unificada, a UML. Porém, a UML é apenas parte de uma metodologia, ela disponibiliza as ferramentas necessárias para se criar e ler modelos, mas não aponta quais modelos deverão ser criados, nem quando deverão ser criados. Essa tarefa é responsabilidade de um processo de desenvolvimento de sistema. Mesmo com todo o avanço das metodologias, a UML precisava interagir com uma metodologia específica que pudesse obter o máximo proveito dos recursos da Linguagem de Modelagem Unificada, foi criado então o Processo Unificado. E foi assim que as respostas para quem está fazendo o que, quando e como puderam ser definidas e um padrão no desenvolvimento de sistemas orientado a objetos pode ser definido. 2.2 ANÁLISE ORIENTADA A OBJETOS Análise é um estudo de um problema antes de qualquer ação (De Marco, 1978). Analisar é você identificar as necessidades de um sistema, e o que este precisa ter para atender os requisitos levantados de acordo com as necessidades do usuário. Analisar não é definir ou pensar como o sistema será desenvolvido, mas sim investigar o problema a ser resolvido com a implantação do sistema. O grande objetivo da Análise Orientada a Objetos é, primeiramente, tornar formal uma visão do mundo real no qual o sistema será desenvolvido, estabelecendo os objetos que serão pontos chaves na estrutura organizacional e também as que o mundo real impõe. Depois, essa análise formaliza a colaboração de um dado conjunto de objetos na execução do sistema que está sendo desenvolvido. 2.3 O PROJETO ORIENTADO A OBJETOS O Projeto Orientado a Objetos é o momento da especificação das partes da construção, ou seja, instruções, guias, recomendações, etc. É utilizado para implementar um sistema em um ambiente específico, em prol da solução do problema.

14 CLASSES As classes são utilizadas para compor o vocabulário do sistema que está sendo desenvolvido, através da abstração de objetos que constituem o domínio do problema. Vamos exemplificar da seguinte maneira: As classes são utilizadas para agrupar os objetos que possuem os mesmos atributos e comportamentos: Todos os alunos de uma escola possuem atributos comuns: nome, sobrenome, data de nascimento, nome da mãe, nome do pai e um comportamento comum. Podemos nos referir a um estudante tanto para inscrevê-lo ou retirá-lo. Os valores destes atributos variam para cada um deles, ou seja, na maioria das vezes, são diferentes, mas todos eles compartilham os mesmos atributos e comportamentos (operações podem ser realizadas sobre eles) Outro exemplo podemos ter uma classe chamada Cachorro, como atributos a um cão podemos considerar: Nome, Peso e Cor do pelo e as operações ou métodos, que representam o que esse cachorro faz podemos citar latir e abanar. Simbolizamos essa classe, seus atributos e operações da seguinte maneira: FIGURA 1 CLASSE CACHORRO

15 OBJETOS Um objeto representa uma coisa física, tangível, uma idéia ou um conceito. Um objeto é uma instância de uma classe. FIGURA 2 EXEMPLO DE OBJETO Um objeto pode ser composto por outro objeto, ou mesmo pode pedir a colaboração de outro objeto enviando uma mensagem, o que denominamos invocar um método do outro. 2.6 ABSTRAÇÃO Abstração é o princípio de ignorar os aspectos de um assunto não relevante para o propósito em questão, tornando possível uma concentração maior nos assuntos principais. (Cood, 1991) Na Análise Orientada a Objetos, podemos considerar duas formas existentes de abstração, de Procedimentos e de Dados.

16 Abstração de procedimentos Consiste em considerar um procedimento como uma operação bem definida, como algo único, mesmo que se utilize mais procedimento interno. Esse tipo de abstração é utilizado quando uma função se divide em outras sub-funções, que por sua vez, decompõe-se em outras funções Abstração de dados Consiste em definir um tipo de dado conforme as operações aplicáveis aos objetos desse tipo, ou seja, a definição de um tipo de dado por seu comportamento e estado utilizando-se métodos. A manipulação deste dado é realizada somente através de seu método. Um exemplo é classificar uma lista a partir das operações aplicadas a ela, como inserção e remoção. Qualquer objeto do tipo lista, só pode sofrer modificações através dessas operações. 2.7 ENCAPSULAMENTO Podemos definir encapsulamento como a separação de um programa em partes, o mais isoladas possível. O objetivo principal é tornar o software mais flexível, fácil de modificar e criar novas implementações. Como exemplo podemos classificar uma dona-de-casa sendo o usuário e um liquidificador sendo o sistema. A dona-de-casa não precisa conhecer o circuito interno para utilizar o liquidificador, apenas os botões que o fazem funcionar. Uma grande vantagem do encapsulamento é que toda parte pode ser modificada sem que os usuários da classe em questão sejam afetados. No exemplo anterior, vamos supor que o liquidificador precisou de reparo e a dona-de-casa chamou um técnico, o técnico poderia facilmente substituir o motor do liquidificador por outro totalmente diferente sem que a dona-de-casa fosse afetada, pois ela ia continuar somente pressionando os botões.

17 HERANÇA O conceito de herança se refere ao compartilhamento de atributos e operações com base numa relação hierárquica entre diversas classes. Uma classe pode ser definida em forma geral e em seguida, refinada em subclasses seguintes. Cada subclasse herda propriedades (atributos e operações) de suas superclasses. Representamos da seguinte maneira: FIGURA 3 HERANÇA O objetivo de utilizar a herança é a intenção de aproveitar código ou comportamento generalizado ou especializar operações ou atributos. O conceito de herança de várias classes é conhecido como herança múltipla. Como exemplo pode-se observar as classes 'aluno' e 'professor', onde ambas possuem atributos como nome, endereço e telefone. Nesse caso pode-se criar uma nova classe chamada, por exemplo, 'pessoa', que contenha as semelhanças entre as duas classes, fazendo com que aluno e professor herdem as características de pessoa, desta maneira pode-se dizer que aluno e professor são subclasses de pessoa. Esta é provavelmente a característica mais discutida da abordagem orientada a objetos. (Mazzola, 1999) 2.9 POLIMORFISMO O termo Polimorfismo foi gerado do grego (poli = muitas e morphos = formas). Na Análise Orientada a Objetos, o polimorfismo permite que referências de tipos de classes mais abstratas representem o comportamento das classes

18 18 concretas que referenciam. Assim, é possível tratar vários tipos de maneira homogenia (através da interface do tipo mais abstrato). Um conceito em teoria de tipo no qual um nome (como uma declaração de variável) pode denotar objetos de muitas subclasses diferentes que são relacionadas por alguma superclasse comum, assim, qualquer objeto denotado por esse nome tem a capacidade de responder a algum conjunto comum de operações de modos diferentes. (Booch, 2000).

19 19 3 UML 3.1 INTRODUÇÃO A UML é a linguagem padrão para especificar, visualizar, documentar e construir artefatos de um sistema e pode ser utilizada com todos os processos ao longo do ciclo de desenvolvimento e através de diferentes tecnologias de implementação. (Furlan, 1998) A UML disponibiliza uma forma padrão de modelagem de projetos de Sistemas, incluindo seus aspectos conceituais tais como processos de negócios e funções do sistema, além de itens concretos como as classes escritas em determinada linguagem de programação, processos de banco de dados e componentes de software reutilizáveis. 3.2 HISTÓRICO COMPLETO As linguagens de modelagem orientadas a objetos surgiram entre a metade da década de 1970 e o final da década de 1980, à medida que o pessoal envolvido com metodologia, diante de um novo gênero de linguagens de programação orientadas a objeto e de aplicações cada vez mais complexas, começou a experimentar métodos alternativos de análise e projeto. A quantidade de métodos orientados a objetos aumentou de pouco mais de 10 para mais de 50 durante o período de 1989 a Muitos usuários desses métodos tiveram dificuldades para encontrar uma linguagem de modelagem capaz de atender inteiramente às suas necessidades. Destacaram-se algumas linguagens como o Booch, o OOSE (Object-Oriented Software Engineering) de Jacobson, e o OMT (Object Modeling Technique) de Rumbaugh. Podemos citar outros métodos importantes como Fusion, Shlaer-Mellor e Coad-Yourdon. Todos eram métodos completos, alguns se destacavam em algum ponto, porém tinham suas limitações. O método Booch destacava-se durante as fases de projeto e construção de sistemas, o OOSE fornecia excelente suporte para captura

20 20 de requisitos, a análise e o projeto em alto nível; o OMT-2 era mais útil com a análise e sistemas de informações com uso de dados[booch, 2000]. Na metade da década de 1990, Grady Booch (Rational Software Corporation), Ivar Jacobson (Objectory) e James Rumbaugh (General Electrics) criadores de métodos orientados a objetos, começaram a pegar as melhores idéias e partiram para a criação de uma linguagem unificada de modelagem. Com isso esperavam fornecer ao mercado uma linguagem mais concreta e madura com os quais os desenvolvedores de ferramentas pudessem criar uma ferramenta mais utilizável. Usando técnicas orientadas a objeto criariam uma linguagem que iria desde o conceito até o sistema executável, não somente a sistemas complexos mas também a sistemas menores e também a outros problemas que não fossem sistemas de informação, podendo ser utilizado por seres humanos e máquinas[furlan, 1998]. A criação da UML iniciou oficialmente em outubro de 1994, quando Rumbaugh se juntou a Booch na Rational. O foco inicial do projeto era a unificação dos métodos Booch e OMT[Furlan, 1998]. O esboço da versão 0.8 do Método Unificado foi lançado em outubro de Mais ou menos na mesma época Jacobson se associou à Rational com a finalidade de incorporar o OOSE no escopo inicial da versão 0.8, resultando o lançamento da versão 0.9 da UML em junho de 1996[Booch, 2000]. Foi então aprovada pela comunidade de engenharia de software em geral. Muitas empresas ficaram interessadas, foi então criada um consórcio com várias empresas interessadas em dedicar recursos com o propósito de trabalhar uma definição mais forte e completa da UML. Empresas que contribuíram para a definição da UML 1.0, Digital Equipment Corporationm Hewlett-Packard, I-Logix, Intel-licorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational, Texas Instruments e Unisys. Resultando uma linguagem de modelagem bem definida, expressiva, poderosa, e que poderia ser aplicada a uma grande variedade de tipos de problemas [Booch, 2000]. A UML foi oferecida para a OMG (Object Management Group) em janeiro de 1997, em resposta à solicitação do próprio OMG de propostas para uma linguagem padrão de modelagem[furlan, 1998]. Entre janeiro a julho de 1997, o grupo original se expandiu, passando a incluir virtualmente todos os participantes e colaboradores da resposta inicial ao OMG, entre os quais se encontravam Andersen Consulting, Ericson, Object Time

21 21 Limited, Platinum Technology, Ptech, Reich Technologies, Softeam, Sterling Software e Taskon. Um grupo foi formado, liberado por Cris Kobryn da MCI Systemhouse e administrado por Ed Eykholt da Rational, com o propósito de formalizar a especificação da UML e de integrar a linguagem a outros esforços de padronização. A versão 1.1 foi entregue a OMG em julho de Em setembro do mesmo ano, essa versão foi aceita pela ADTF (Analysis and Design Task Force) e pelo Architecture Board do OMG e, posteriormente submetida a votação de todos os membros da OMG. A versão 1.1 foi adotada pela OMG em 14 de novembro de 1997[Booch, 2000]. A manutenção da UML foi então assumida pela RTF (Revision Task Force) do OMG, sob a responsabilidade de Cris Kobryn. A RTF lançou uma revisão editorial, a UML 1.2., em junho de No final do mesmo ano, a RTF lançou a UML 1.3[Furlan, 1998]. 3.3 ACEITAÇÃO Para se estabelecer a UML, os desenvolvedores perceberam que a linguagem teria que estar acessível para todos, então, preocuparam-se em deixá-la aberta aos desenvolvedores, onde os mesmos pudessem criar seu próprio método de trabalho. Empresas desenvolvedoras de ferramentas estão livres para criarem uma ferramenta aqueda ao uso da UML. Devido a necessidade de criação da UML empresas e profissionais liberais da área estão desenvolvendo estudos para melhor aplicá-la. 3.4 PADRONIZAÇÃO OMG Quando se iniciaram os trabalhos para criação da UML, os criadores tinham como intenção fazer sua aceitação com a distribuição da linguagem a vários desenvolvedores. A OMG (Object Management Group) fez um requerimento por uma linguagem de modelagem padrão. Então houve interesse dos criadores da UML em padronizá-la, para isso foi preciso que os mesmos aprimorassem a qualidade da

22 22 linguagem para tal. Pois para serem realmente utilizadas por empresas era necessário sua padronização. 3.5 APLICAÇÃO DA UML A UML pode ser utilizada para modelar as várias fases de um sistema, desde o levantamento de requisitos até a geração do código, pode ser aplicada em qualquer tipo de sistema em termos de diagramas orientado a objeto. Normalmente. É mais usada na modelagem de Softwares sob o conceito de orientação a objetos, mas também, pode ser aplicada em sistemas mecânicos, de engenharia geral, totalmente desligados do ramo da informática, também pode ajudar na organização de processos de uma empresa. Numa classificação geral, podemos dizer que ela pode ser aplicada em várias áreas diferentes para documentar e transmitir qualquer coisa da empresa aos processos de negócios para o software.

23 23 4 ETAPAS DE DESENVOLVIMENTO DE UM SISTEMA UTILIZANDO UML 4.1 ANÁLISE DE REQUISITOS Um requisito é uma funcionalidade ou condição que o sistema deverá ter, para não errar no levantamento dos requisitos e os identificar adequadamente, aplica-se um conjunto de técnicas de modo a perceber detalhadamente o que o sistema, necessariamente, deverá efetuar. Fazem parte deste conjunto de técnicas: Reuniões com os interessados; Elaboração de questionários sobre o sistema; Observação das atividades e do funcionamento diário das rotinas da empresa; O recolhimento e análise de documentações diversas; A elaboração de pequenos protótipos do sistema que permitam validar mais facilmente a percepção obtida (tendo em vista que uma imagem é fundamental para o entendimento do que vai ser feito); Preocupação para encontrar a melhor solução; Analisar, não somente, as funcionalidades atuais, mais também uma situação futura a ser atingida; Esta fase captura as intenções e necessidades dos usuários do sistema a ser desenvolvido através do uso de funções chamadas use-cases. (Barros, 2001) Deve-se sempre ter em vista a melhor solução, pois as vezes aquilo que o utilizador pede não é sempre o que ele necessita. Através do desenvolvimento de casos de uso (em UML chamamos de Use-Cases ), as entidades externas do sistema (em UML chamamos de atores externos ) que interagem e possuem interessa no sistema, são modelados entre as funções que o mesmo vai desenvolver, funções, estas chamadas de use-cases. Os atores externos e os use-case são modelados através de relacionamentos que possuem comunicação por associação entre eles ou são desmembrados em hierarquia. Descrevemos um use case através de um texto, especificando os

24 24 requisitos do ator externo que utilizará esse use case. Um use case tanto pode depender de um ou mais use-case, como também, pode ter seus dependentes. Através do diagrama de use-case ou diagrama de casos de uso mostraremos aos atores externos, ou seja, futuros usuários, o que estes podem esperar do sistema. Vamos exemplificar utilizando um sistema acadêmico, considera-se que os clientes usuários, professores e secretaria da escola desejam que o sistema ofereça os seguintes serviços: Possibilidade de Cadastramento de todos os alunos matriculados no curso. Isto nos mostra que o sistema deverá ter um serviço de inclusão de novos alunos e manutenção da base de dados dos alunos. Esta funcionalidade do sistema poderia ser representada pelo caso de uso Cadastrar Aluno. Possibilidade de Cadastramento de todos os professores que trabalham nesta unidade escolar e ministram disciplina no curso. Isto nos mostra que o sistema deverá ter um serviço de inclusão de novos professores e manutenção da base de dados dos professores. Esta funcionalidade do sistema poderia ser representada pelo caso de uso Cadastrar Professor. Possibilidade de registro das disciplinas oferecidas no curso, com a capacidade de registrar novas disciplinas e a manutenção da base de dados das disciplinas. Este uso do sistema será representado pelo caso de uso Cadastrar Disciplina. Possibilidade de registro da matrícula dos alunos em cada semestre. Este serviço será representado pelo caso de uso Registrar Matrícula. Possibilidade da emissão da confirmação de matrícula para cada aluno, contendo a lista de disciplinas nas quais um aluno se matriculou para aquele semestre. Este serviço será representado pelo caso de uso Emitir Confirmação de Matrícula. O conjunto de casos de uso definidos representa os serviços ou uso esperado pelos clientes que utilizaram o sistema. Assim como para os atores, nem

25 25 sempre é possível efetuar um levantamento completo e definitivo dos casos de uso em uma primeira tentativa. Ao longo do processo de refinamento, novos casos de uso poderão aparecer e outros sofrerem alterações. 4.2 ANÁLISE Nesta fase dominamos somente as classes que pertencem ao domínio principal do problema, ou seja, classes técnicas mais complexas não estarão nesse diagrama. A fase de análise preocupa-se com as primeiras abstrações(classes e objetos) e mecanismos presentes no contexto do problema. (Larman, 2000) Descrevemos as classes nos Diagramas de Classes e também para ajudar na descrição dos casos de uso, podendo estar ligado umas nas outras por meio de relacionamentos. 4.3 PROJETO Projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. Neste momento partiremos para as soluções técnicas, através dos resultados obtidos nas fases de análise. Serão adicionadas novas classes para oferecer uma infra-estrutura técnica, tais como: interface do usuário e periféricos, banco de dados, interação com outros sistemas, e outras mias. Este é o momento da junção da fase de análise com as classes técnicas da nova infra-estrutura, podendo assim, alterar tanto o domínio principal do problema quanto a infraestrutura. É justamente, com a elaboração do projeto que obtemos detalhadamente as especificações para dar início a fase da programação. 4.4 PROGRAMAÇÃO Esta fase só terá um bom desempenho se o projeto for muito bem elaborado, neste momento converteremos as classes da fase do projeto para o código da linguagem orientada a objetos escolhida.

26 26 Em UML durante a elaboração dos modelos de análise e projeto, não devemos traduzi-los em códigos, cabendo esta tarefa a fase de programação. 4.5 TESTES Na fase de teste, testamos o programa ao máximo na intenção de descobrir erros. Cada rotina e método são testados minuciosamente, bem como a integração de todos os processos e a aceitação. As rotinas devem ser testadas de duas formas, uma pelo programador, que sabe tudo sobre técnica, pontos críticos das classes e subclasses, e outra pelas rotinas do usuário, pois ele irá fazer o teste do seu modo, tendo em vista uma visão da rotina como um todo. Os testes de integração são feitos usando as classes e seus componentes de integração para verificar se estas classes estão realmente colaborando uma com as outras conforme especificado nos modelos. Nos testes de aceitação é verificado se o sistema está de acordo com o especificado no diagramas de use-cases. Por fim, o sistema é testado pelo usuário final e este verá se o mesmo está de acordo com suas necessidades expressas no começo do projeto.

27 27 5 MODELOS DE ELEMENTOS 5.1 DEFINIÇÃO Os conceitos utilizados nos diagramas são chamados de modelos de elementos (Barros, 2001). Um modelo de elemento é definido com a semântica, a definição formal do elemento com o exato significado do que ele representa sem definições duvidosas ou ambíguas e também define sua representação gráfica que é mostrada nos diagramas da UML. Um elemento pode aparecer em diversos tipos de diagrama, mas existem regras que definem quais elementos podem aparecer em tais diagramas. Podemos citar como exemplos de modelos de elementos: classes, objetos, estados, pacotes etc. Os relacionamentos também são modelos de elementos e são usados para conectar outros modelos de elementos entre si. Para entrarmos definitivamente nesta parte de elementos e diagramas, precisamos estar desprovidos de dúvidas quanto classes, objetos, estado, etc. Vamos relembrar! 5.2 RELEMBRANDO CLASSES Vimos mais acima, que classe é a descrição de um conjunto de objetos que compartilham os mesmos atributos, relacionamentos, operações e semânticas e podem ser implantadas em uma ou mais interfaces. Como exemplo demos a classe cachorro, no capítulo 2, no item Nomes Todas as classes devem ter um nome que as diferencie das demais. Como no exemplo do capítulo 2, o nome da nossa classe é cachorro.

28 Relembrando atributos Vimos que um atributo é uma prioridade de uma classe, que descreve um intervalo de valores que as instâncias da prioridade podem apresentar. No exemplo do capítulo 2, usamos como atributos para a nossa classe cachorro os atributos: Nome, Peso e Cor do Pelo. 5.3 OPERAÇÕES São processos que as classes podem realizar. Operações correspondem claramente a métodos em uma classe. No nível de especificação, as operações correspondem a métodos públicos. Normalmente você não mostra as operações que simplesmente manipulam atributos, porque elas podem ser freqüentemente inferidas. Portanto você terá que identificar se um atributo é somente leitura, isto é, seu valor nunca muda. No modelo de implementação, você também pode querer mostrar operações privativas (private) e protegidas (protected). Uma classe pode ter várias operações ou simplesmente nenhuma, elas são respresentadas logo após os atributos. No nosso exemplo da classe cachorro, do capítulo 2, as operações eram latir e abanar Relembrando objetos Vimos que objetos são elementos que podemos manipular, acompanhar seu comportamento, criar, interagir com ele, ou até, destruí-lo. Ele pode existir no mundo real ou pode ser uma derivação de estudos da estrutura ou comportamento de outros objetos do mundo real. Corresponde a qualquer coisa que tenha algum significado para uma dada aplicação.

29 ESTADOS Todos objetos possuem um estado que significa o resultado de atividades executadas pelo objeto, normalmente este estado é determinado pelos valores dos atributos e ligações com outros objetos. Um objeto muda de estado quando algo acontece no sistema, este fato de mudança de estado de um objeto, chamamos de evento. Analisando essas mudanças de estado que um objeto pode sofrer, podemos prever todos os possíveis comportamento de um objeto e os eventos que o mesmo possa sofrer. Um estado pode ter três compartimentos: Nome do evento Mostra o nome do evento, na maioria das vezes este nome descreve o que este estado realiza. Atributos Mostra todas as possíveis variáveis do estado, onde os atributos do objeto em questão podem ser listados, consultados e atualizados. Atividades Aqui, podemos listar os eventos e ações. Esta dividido em três eventos: Entrar (define as atividades no momento em que o objeto entra naquele estado), Sair (define as atividades que o objeto executa antes de passar para o próximo estado) e Fazer (define as atividade que o objeto executa enquanto se encontra naquele estado). 5.5 PACOTES É um mecanismo de propósito geral para organizar elementos de modelos em grupo, podendo, inclusive, estar aninhando dentro de outros pacotes (pacotes subordinados). (Furlan,1998) O pacote tem uma grande similaridade com a agregação. O fato de um pacote ser composto de modelos de elementos cria uma agregação de composição. Se este for destruído, todo o seu conteúdo também será.

30 COMPONENTES Pode ser tanto um código em linguagem de programação, quanto um código executável já compilado. Exemplo, se um sistema é desenvolvido em Java, cada arquivo.java ou.class é um componente do sistema, e será mostrado no diagrama de componentes que o utiliza. 5.7 RELACIONAMENTOS Ligam classes e objetos entre si, criando relações lógicas entre essas entidades. Podemos classificá-los em 3 tipos: Associação É uma conexão entre as classes, e significa também, uma conexão entre os objetos daquelas classes. Em UML, uma associação é definida com um relacionamento que descreve uma série de ligações, onde a ligação é definida como a semântica, entre as duplas de objetos ligados. Generalização - É um relacionamento de um elemento mais geral e outro mais específico. O elemento mais específico pode conter apenas informações adicionais. Uma instância (um objeto é uma instância de uma classe) do elemento mais específico pode ser usada onde o elemento mais geral seja permitido. Dependência ou refinamentos - Dependência é um relacionamento entre elementos, um independente e outro dependente. Uma modificação é um elemento independente afetará diretamente elementos dependentes do anterior. Refinamento é um relacionamento entre duas descrições de uma mesma entidade, mas em níveis diferentes de abstração. 5.8 ASSOCIAÇÕES É uma conexão entre classes, e também significa que é uma conexão entre objetos daquelas classes. Em UML, uma associação é definida com um relacionamento que descreve uma série de ligações, onde a ligação é definida como a semântica entre as duplas de objetos ligados.

31 Agregação A agregação é um caso particular da associação. A agregação indica que uma das classes do relacionamento é uma parte, ou está contida em outra classe. As palavras chaves usadas para identificar uma agregação são: "consiste em", "contém", "é parte de" Generalizações A generalização é um relacionamento entre um elemento geral e um outro mais específico. O elemento mais específico possui todas as características do elemento geral e contém ainda mais particularidades. Um objeto mais específico pode ser usado como uma instância do elemento mais geral. A generalização, também chamada de herança, permite a criação de elementos especializados em outros. A generalização pode ser de dois tipos, normal ou restrita Generalização normal Na generalização normal a classe mais específica, chamada de subclasse, herda tudo da classe mais geral, chamada de superclasse. Os atributos, operações e todas as associações são herdados. Uma classe pode ser tanto uma subclasse quanto uma superclasse, se ela estiver numa hierarquia de classes que é um gráfico onde as classes estão ligadas através de generalizações. A generalização normal é representada por uma linha entre as duas classes que fazem o relacionamento, sendo que se coloca uma seta no lado da linha onde se encontra a superclasse indicando a generalização Generalização restrita Uma restrição aplicada a uma generalização especifica informações mais precisas sobre como a generalização deve ser usada e estendida no futuro. As restrições a seguir definem as generalizações restritas com mais de uma subclasse:

32 32 Generalizações de Sobreposição e Disjuntiva: Generalização de sobreposição significa que quando subclasses herdam de uma superclasse por sobreposição, novas subclasses destas podem herdar de mais de uma subclasse. A generalização disjuntiva é exatamente o contrário da sobreposição e a generalização é utilizada como padrão. Generalizações Completa e Incompleta: Uma restrição simbolizando que uma generalização é completa significa que todas as subclasses já foram especificadas, e não existe mais possibilidade de outra generalização a partir daquele ponto. A generalização incompleta é exatamente o contrário da completa e é assumida como padrão da linguagem. 5.9 DEPENDÊNCIA E REFINAMENTOS Dependência é um relacionamento entre elementos, um independente e outro dependente. Uma modificação a um elemento independente, afetará diretamente elementos dependentes do anterior. Uma relação de dependência é simbolizada por uma linha tracejada com uma seta no final em um dos lados do relacionamento. E sobre essa linha, o tipo de dependência que existe entre essas duas classes. Refinamento é um relacionamento entre duas descrições de uma mesma entidade, mas em níveis diferentes de abstração. Estes, são simbolizados por uma linha tracejada com um triângulo no final de um dos lados do relacionamento e são usados em modelos de coordenação. Em projetos maiores, todos os modelos que são feitos devem ser coordenados. Coordenação de modelos pode ser usada para mostrar modelos em diferentes níveis de abstração que se relacionam e mostram também como modelos em diferentes fases de desenvolvimento se relacionam MECANISMOS GERAIS Para tratar informações adicionais, a UML utiliza alguns mecanismos em seus diagramas: Ornamentos: Ornamentos gráficos são anexados aos modelos de elementos em diagramas e adicionam semântica ao elemento. Como exemplo de ornamento, podemos citar, a técnica de separar um tipo de uma instância.

33 33 Quando um elemento representa um tipo, seu nome é mostrado em negrito, quando o mesmo elemento representa a instância de um tipo, seu nome é escrito em sublinhado e pode significar tanto o nome da instância, quanto o tipo. Notas: Para permitir adicionar informações, a UML provê a capacidade de adicionar Notas. Uma nota pode ser colocada em qualquer lugar em um diagrama, e pode conter qualquer tipo de informação.

34 34 6 DIAGRAMAS 6.1 CONCEITOS O objetivo de se fazer modelagem, é você simplificar a realidade para um melhor entendimento do sistema que está sendo desenvolvido. Em UML, utilizamos blocos distintos, tais como: classes, interfaces, colaborações, componentes, dependências, associações, etc. Os diagramas são para visualizarmos os blocos em construção. Os diagramas utilizados em UML são separados em nove tipos: Diagrama de Casos de Uso, Classes, Objetos, Estados, Seqüência, Colaboração, Atividades, Componentes e Execução. Na seqüência trataremos cada um desses tipos de Diagrama e citaremos dois, detalhadamente, mostrando graficamente gráficos apresentando rotinas diretas do nosso sistema de carimbos. 6.2 Diagrama de Casos de Uso Um diagrama de caso de uso, ilustra um conjunto de casos de uso, para um sistema, os atores e a relação entre os atores e os casos de uso. (Larman,2000). Esse tipo de diagrama é utilizado pra mostrar como a empresa ou o sistema funciona, ou como os usuários desejam que ele funcione. Os caso de uso, geralmente são ponto de partida na análise orientada a objetos na UML. Esse modelo consiste de atores e casos de uso. Os atores representam usuário e outros sistemas que interagem com o modelado. Geralmente, representamos o ator, dentro de um diagrama por um homem palito. Os casos de uso mostram como o sistema se comporta, cenários que ele percorre em resposta ao estímulo do ator. Representamos os casos de uso por elipses. No modelo de caso de uso, o relacionamento entre um ator e um caso de uso representa a participação deste ator no caso de uso. Além deste relacionamento, existem dois outros tipos de relacionamento entre casos de uso:

35 35 Estender : É representado graficamente por uma seta com o esteriótipo <<extends>>, que nos permite entender que o caso de uso destino pode incluir o comportamento especificado pelo caso de uso origem; Usar: Representado por uma seta com o esteriótipo <<uses>>, nos permite entender que o caso de uso origem inclui o comportamento do caso de uso destino. Incluir: Representado por uma seta com o esteriótipo <<include>> é utilizado para incluir um comportamento comum de um caso de uso incluído para um caso de uso base, a fim de suportar a reutilização do comportamento comum. Exemplo de Diagrama de Caso de Uso: FIGURA 4 DIAGRAMA DE CASO DE USO 6.3 DIAGRAMA DE CLASSES Representamos uma classe em UML, com uma caixa retangular com três divisões: Nome da Classe, Lista de Atributos, e o último com Operações, como vimos no capítulo 2, a classe Cachorro. As associações representam relacionamentos estruturados entre os objetos de diferentes classes, e são representados graficamente através de uma linha conectando as classes. Uma associação pode ter um nome. E nas

36 36 extremidades da linha, que representa uma associação pode ter nome de papéis mostrando como a classe é vista pelas outras classes na associação. A multiplicidade especifica quantas instâncias de uma classe relaciona-se a uma única instância de uma classe associada. A multiplicidade é representada por um intervalo de valores possíveis, no seguinte formato: limite_inferior...limite_superior, onde esses limites são valores inteiros (o caracter * pode ser usado como limite_superior para indicar falta de limite). A agregação é uma forma especial de associação que representa o relacionamento todo-parte entre objetos. Ela é representada incluindo-se um losango na extremidade do objeto todo do relacionamento todo-parte. A generalização é uma ferramenta poderosa para a abstração. É um relacionamento existente entre uma classe mais geral (superclasse) e uma classe mais específica (subclasse), onde a classe mais específica é consistente com a mais geral e adiciona informações a ela. A generalização é representada por uma linha com um triângulo, que liga a classe mais específica a mais genérica. Exemplo de Diagrama de Classes: FIGURA 5 DIAGRAMA DE CLASSE 6.4 DIAGRAMA DE OBJETOS Fazem a modelagem de instância de itens contidos em diagrama de classes. Mostra um conjunto de objetos e seus relacionamentos em determinado

37 37 ponto no tempo. Estes diagramas não são importantes apenas para a visualização, especificação e documentação de modelos estruturais, mas também para a construção de aspectos estático de sistemas por meio de engenharia de produção e engenharia reversa [Booch, 2000]. Este tipo de diagrama cobrem um conjunto de instâncias dos itens encontrados nos diagramas de classes. Portanto, esse diagrama expressa a parte estática de uma interação, composta pelos objetos que colaboram entre si, mas sem qualquer uma das mensagens passadas entre eles. Nos dois casos, o Diagrama de Objetos congela um momento no tempo. São usados para fazer a modelagem da visão de projeto estática ou da visão de processo estática de um sistema, da mesma forma como faz os diagramas de classes, mas a partir da perspectiva de instâncias reais ou prototípicas. Este tipo de diagrama permite que você faça a modelagem de dados estáticos. Vejamos um exemplo de Diagrama de Objetos: FIGURA 6 DIAGRAMA DE OBJETOS 6.5 DIAGRAMA DE ESTADOS São usados para modelar o comportamento dinâmico de um sistema. Mostram o ciclo de vida de um objeto em níveis de detalhe arbitrariamente simples ou complexos [Larman, 2000].

38 38 Visualizam a seqüência de estados que um objeto ou uma interação percorre durante sua vida em resposta a estímulos recebidos, junto com suas próprias ações e respostas. Os estados representam as condições dos objetos em um determinado momento. Neste diagrama os eventos são incidentes que fazem o objeto mudar de um estado para outro. As linhas de transição descrevem o movimento de um estado para outro. Cada linha de transição é rotulada com o evento que causou a transição. Estudamos o Diagrama de Estados para que pudéssemos visualizar melhor todos os estados que passavam os objetos do diagrama da empresa de carimbos durante ações rotineiras do sistema, portanto, vamos mostrar mais de um exemplo neste diagrama, que se trata do nosso sistema.

39 39 Exemplo 1 Construímos estes diagramas de acordo com nosso sistema. Utilizamos para isso duas ações de rotina que são Cadastrar Venda e cadastrar Preços. Cadastrar Venda Cadastrar Preços Inicio das operações Digitando os dados da Venda Inicio das operações Digitando os dados dos preços ValidandoDados() ValidandoDados() Concluindo a venda Concluindo o cadastro ValidandoDados() ValidandoDados() Efetuando a Venda Efetuando o cadastro Fim das operações Fim das operações FIGURA 7 CADASTRAR VENDAS E PREÇOS

40 40 Exemplo 2 Diagrama de Estado Cadastrar Cliente e Cadastrar Fornecedor Cadastrar Cliente Cadastrar Fornecedor Inicio das operações Digitando os dados do cliente Inicio das operações Digitando os dados do fornecedor ValidandoDados() ValidandoDados() Concluindo o cadastro Concluindo o cadastro ValidandoDados() ValidandoDados() Efetuando o cadastro Efetuando o cadastro Fim das operações Fim das operações FIGURA 8 CADASTRAR CLIENTE E FORNECEDOR

41 41 Exemplo 3. Diagrama de Estado Cadastrar Débito e Cadastrar Credito. Cadastrar Debito Cadastrar Credito Inicio das operações Preparando os dados para o debito Inicio das operações Preparando os dados para o credito Efetuando debito Efetuando credito Concluindo o debito Concluindo o credito FIGURA 9 CADASTRAR DÉBITO E CRÉDITO

42 42 Exemplo 4 Diagrama de Estado Cadastrar Produto e Cadastrar Usuário Cadastrar Produto Cadastrar Usuário Inicio das operações Digitando os dados do produto Inicio das operações Digitando os dados do usuário ValidandoDados() ValidandoDados() Concluindo o cadastro Concluindo o cadastro ValidandoDados() ValidandoDados() Efetuando o cadastro Efetuando o cadastro Fim das operações Fim das operações FIGURA 10 CADASTRAR PRODUTO E USUÁRIO

43 43 Exemplo 5 Diagrama de Estado Cadastrar Movimentação e Cadastrar Pedido Cadastrar Movimentação Cadastrar Pedido Inicio das operações Preparando os dados para movimentação Inicio das operações Preparando os dados para o pedido Efetuando a movimentação Efetuando o pedido Concluindo a movimentação Concluindo o pedido Fim das operações Fim das operações FIGURA 11 CADASTRAR MOVIMENTAÇÃO E PEDIDO 6.6 DIAGRAMA DE SEQUÊNCIA São usados para modelar a interação entre objetos dentro de um sistema, tipicamente, este tipo de diagrama captura o comportamento de um único caso de uso. O Diagrama apresenta os objetos e as mensagens que são passadas entre estes objetos dentro caso de uso. Os objetos são representados por linhas tracejadas verticais e a passagem de mensagens entre dois objetos são representados por vetores horizontais. As mensagens são desenhadas cronologicamente do topo a base do diagrama.

44 44 Exemplo de Diagrama de Seqüência FIGURA 12 DIAGRAMA DE SEQUÊNCIA 6.7 DIAGRAMA DE COLABORAÇÃO É uma outra alternativa para a modelagem de interações entre objetos de um sistema. Esse tipo de diagrama focaliza no relacionamento entre os objetos e na compreensão dos efeitos sobre um objeto durante um cenário. Os objetos são conectados através de associações e cada associação representa uma instância de associação entre as respectivas classes envolvidas. As associações mostram as mensagens enviadas entre os objetos, e a seqüência destas mensagens é determinada usando-se números seqüenciais. O Diagrama de Colaboração dá ênfase à ordenação estrutural em que as mensagens são trocadas entre os objetos de um sistema. Exemplo de Diagrama de Colaboração: FIGURA 13 DIAGRAMA DE COLABORAÇÃO

45 DIAGRAMA DE ATIVIDADES Este tipo de diagrama representa os fluxos conduzidos por processamento, é essencialmente um gráfico de fluxo de controle de uma atividade para outra, comumente isso envolve a modelagem das etapas seqüenciais de um processo computacional. Este tipo de Diagrama é extremamente importante para a construção de sistemas executáveis por meio de engenharia de produção reversa. O principal objetivo deste diagrama é focar nos fluxos dirigidos pelo processamento interno e descrever o comportamento de processamentos paralelos. São usados para detalhar classes, implementação de operações e casos de uso, enquanto os diagramas de estado são usados para especificar o comportamento global de um tipo. Esse tipo de diagrama representa o que acontece, mas não quem faz o que, isso nos leva a crer que esse tipo de diagrama não diz qual classe é responsável por qual atividade. Testamos nosso sistema de Carimbos utilizando também, o diagrama de atividades. Segue abaixo os resultados.

46 46 Exemplo de Diagrama de Atividades de Venda e Preço da empresa de carimbos: CADASTRAR VENDA - CADASTRAR PREÇOS FIGURA 14 CADASTRAR VENDAS E PREÇOS

47 47 Exemplo 2 Diagrama de Atividades de Cliente e Fornecedor CADASTRAR CLIENTE - CADASTRAR FORNECEDOR FIGURA 15 CADASTRAR CLIENTE E FORNECEDOR

48 48 Exemplo 3 Diagrama de Atividades de Débito e Crédito CADASTRAR DÉBITO - CADASTRAR CRÉDITO FIGURA 16 CADASTRAR DÉBITO E CRÉDITO

49 49 Exemplo 4 Diagrama de Atividades de Produto e Usuário CADASTRAR PRODUTO - CADASTRAR USUÁRIO FIGURA 17 CADASTRAR PRODUTO E USUÁRIO

50 50 Exemplo 5 Exemplo de Diagrama de Atividades de Movimentação e Pedido CADASTRAR MOVIMENTAÇÃO - CADASTRAR PEDIDO FIGURA 18 CADASTRAR MOVIMENTAÇÃO E PEDIDOS

51 DIAGRAMA DE COMPONENTES Mostram dependências entre componentes de software. (Furlan,1998). Os diagramas de componentes representam, de forma estática, aspectos físicos do sistema sendo modelado. São importantes tanto para visualizar, especificar e documentar sistemas baseados em componentes quanto para construir sistemas através de engenharia reversa (reverse) e direta (forward). São tipicamente usados para: Modelar a organização do código fonte; Modelar lançamentos de executáveis; Modelar fisicamente um banco de dados; Modelar sistemas adaptativos; Engenharia de produção e engenharia reversa; Exemplo de Diagrama de Componentes: FIGURA 19 DIAGRAMA DE COMPONENTES 6.10 DIAGRAMA DE IMPLANTAÇÃO Os diagramas de implantação são diagramas que mostram a configuração de nós de processamento em tempo de execução e os componentes que neles existem. Os diagramas de implantação não são importantes somente para visualizar, especificar e documentar sistemas embutidos, cliente/servidor e distribuídos, mas também para o gerenciamento de sistemas por engenharia de produção e engenharia reversa.