Modelagem de Processos

Transcrição

1 Modelagem de Processos

2 Professor conteudista: Ricardo Holderegger

3 Sumário Modelagem de Processos Unidade I 1 INTRODUÇÃO Documentação importante Histórico do sistema Sistemas complexos A documentação na Antiguidade DESENVOLVIMENTO DE SOFTWARES ORIENTADO A OBJETOS...7 Unidade II 3 MODELAGEM DE SISTEMAS Os desenvolvedores de sistemas podem escolher entre quatro caminhos Modelos de dados Modelos de processos Modelos de objeto UML Para que é utilizado a UML?...16 Unidade III PROCESSO DE DESENVOLVIMENTO DE SISTEMAS Fluxo de trabalho em relação aos requisitos Diagramas Diagramas de casos de uso Diagrama de atividades Diagrama de classes Acessibilidade dos atributos e métodos: Representação de uma classe Representação de uma interface Associação Generalização Agregação e composição Diagrama de classes outras considerações Diagrama de objetos Diagrama de sequência Diagrama de estados Diagrama de pacotes...30

4 Unidade IV 6 RELACIONAMENTOS Associação Multiplicidade de associação Associação reflexiva Agregação Associação ou agregação Classe de uma associação de classe Relacionamento entre pacotes Diagrama de componentes Diagrama de implantação MODELAGEM CONCEITUAL Elementos básicos do modelo conceitual...38

5 MODELAGEM DE PROCESSOS Unidade I 1 INTRODUÇÃO O termo documentação tornou-se um conceito básico nos negócios, na administração, na ciência e na tecnologia da informação. A modelagem nada mais é que uma forma de documentar com detalhes os passos da geração de um sistema. 1.1 Documentação importante 1 20 Atualmente, o documento é aparentemente mais importante do que aquilo sobre o que ele trata. Neste sentido, pode-se considerar o caso das instituições e autoridades governamentais, em que uma pessoa somente existe se houver documentos que certifiquem esse fato. Uma pessoa sem documentos não possui uma identidade oficial. Da mesma forma, nas corporações, embora um contrato comercial que cria um vínculo legal possa ser estabelecido com um aperto de mãos, a prática comum é colocar os termos desse contrato no papel. Todos os dias, milhões de transações em todo o mundo são acompanhadas de documentos, eletrônicos ou não, podendo ser notas fiscais, pedidos de compras, faturas, recibos e assim por diante. Os documentos também são importantes para comunicar resultados científicos entre cientistas e o estudo científico, além do trabalho experimental e do estudo de campo. A reputação de um cientista é medida pelo número de documentos publicados e pela frequência com que é citado nos documentos produzidos por outros cientistas. Isto é importante para os projetistas 1

6 Unidade I de sistemas de documentação: quanto mais fácil for fazer referência cruzada em um sistema, maior é a possibilidade de ele ser adotado pela comunidade científica. 1.2 Histórico do sistema Observando o processo de desenvolvimento de um sistema por meio de uma visão de alto nível, percebemos que ele possui uma estrutura específica (Figura 1). Análise Projeto Implementação Teste Figura 1 - Esboço do processo de desenvolvimento. Fonte: Fowler e Scott, Este processo se dá de forma iterativa e incremental, no qual o sistema ou o software não é implementado em um instante no fim do projeto, mas é, ao contrário, desenvolvido e implementado em etapas. A fase de construção consiste de várias iterações, em que cada iteração constrói software de qualidade de produção, testado e integrado, que satisfaz um subconjunto de requisitos de projeto. Cada iteração contém todas as fases usuais do ciclo de vida da análise, do projeto, da implementação e do teste. As duas primeiras fases são a análise e o projeto. Durante a análise, estabelece-se a lógica do domínio da aplicação para o projeto e decide-se o escopo do projeto. No projeto, são coletados os requisitos mais detalhados para se estabelecer uma arquitetura básica e criar um plano para a construção do sistema. 2 Os projetos variam de acordo com o volume de formalidade que eles possuem. Projetos de muita formalidade têm muitos documentos formais a ser entregues, reuniões formais, encerramentos formais. Projetos de pouca formalidade podem ter uma fase de concepção que consiste de um bate-papo de 2

7 MODELAGEM DE PROCESSOS uma hora com o patrocinador do projeto e um plano que cabe em uma folha de papel. Naturalmente, quanto maior o projeto, maior formalidade é necessária. A implementação elabora o sistema em uma série de iterações. Cada iteração é um novo miniprojeto, com casos de uso designados para cada iteração. Você termina a iteração com uma demonstração para o usuário e realiza testes de sistema na fase seguinte para confirmar que os casos de uso foram construídos corretamente. O objetivo deste processo é reduzir o risco. O risco, geralmente, aparece porque casos difíceis são deixados para o fim do projeto. As iterações dentro da implementação são tanto incrementais quanto iterativas As iterações são incrementais na função. Cada iteração é construída sobre os casos de uso desenvolvidos nas iterações prévias. As iterações são iterativas em termos da base de código. Cada iteração implicará que alguns trechos de código existentes sejam reescritos para torná-los mais flexíveis. 2 O teste e a integração são tarefas extensas, e elas sempre demoram mais do que as pessoas imaginam. Deixadas para o fim, elas são difíceis e desanimadoras. Os testes visam identificar quaisquer possíveis erros de construção ou conceito antes que o aplicativo seja disponibilizado para o usuário. Essa fase é de fundamental importância para a confiança do software, pois aplicativos que apresentam muitos erros e interferem no desempenho de seus usuários tendem a ter uma pequena aderência e uma vida curta. 3

8 Unidade I 1.3 Sistemas complexos A documentação tornou-se o centro da infraestrutura de grandes sistemas de TI não apenas porque a autoria, o gerenciamento e a recuperação de documentos são áreas de aplicação importantes, mas também porque os componentes de software estão se tornando cada vez mais complexos. Nos primórdios da computação, na programação com Assembler (Figura 2) ou Fortran, as sub-rotinas eram construções bastante simples que podiam ser facilmente controladas com parâmetros igualmente simples: inteiros simples, números de ponto flutuante, strings e endereços. ; the easiest way to print hello, world! name hi org 0h jmp Start ; jump over string declaration msg db hello, world, 0Dh, 0Ah, 24h start: lea dx, msg ; load effective address of msg into dx. mov ah, 09h ; print function is 9 int 21h ; do it! mov ah, 0 int 16h ; wait for any key any... ret ; return to operating system. 1 Figura 2 Código Assembler Fonte: < Nos dias atuais, os componentes reutilizáveis de softwares podem ser módulos enormes e bastante complexos, normalmente apoiados por interfaces repletas de recursos, o que tornou o entendimento dos sistemas modernos uma atividade altamente complexa. Por exemplo, um serviço Web. O protocolo de um serviço Web é descrito com uma linguagem chamada WSDL (Web Service Description Language), e a sintaxe das mensagens passada para um serviço Web pode ser descrita com a linguagem 4

9 MODELAGEM DE PROCESSOS XML (Quadro 1), inicialmente chamada SOAP (Simple Object Access Protocol). <?xml version= 1.0 encoding= UTF-8?> <arder orderno= NILE01709 orderdate= 04/23/2002 > <customer customerno= BD > <name> <first>john</first> <last>doe</last> </name> <address> <street>747 Sunset Strip</street> <town>miami</town> <zip>99999</zip> <state>fl</state> <country>usa</country> </address> </customer> <orderitem amount= 1 > <CD productno= year= 1999 > <title>surte africaine</title> <publisher>harmonia mundo</publisher> <contributor kind= performer >Romano</contributor> <contributor kind= performer >Sclavis</contributor> <contributor kind= performer >Texier</contributor> <contributor kind= performer >Ee Querrec</contributor> </CD> </orderitem> <orderitem amount= 1 > <book ISBN= year= 1977 > <title>on Photography</title> <publisher>penguin</publisher> <author>susan Sontag</author> <prece>19.9</prece> </book> </OrderItem> </arder> Quadro 1 - Exemplo de código XML. Compreende um pedido de compra serializado em XML, que poderia ser enviado a um sistema de compras que o executaria. Fonte: Daun, 2004.

10 Unidade I 1.4 A documentação na Antiguidade Utilizando padrões de documento, o setor de TI pode aproveitar quase nove mil anos da experiência humana. O conceito de documentação está totalmente relacionado ao propósito do desenvolvimento da representação gráfica de elementos que possam resgatar a fatos passados. O advento dos sistemas de escrita remonta há nove mil anos e provavelmente coincidiu com a transição das sociedades de caça e coleta para sociedades mais agrárias. As evidências dos sistemas de escrita apareceram primeiramente em pedras entalhadas, utilizadas como símbolos de contagem, provavelmente usadas para contar certas propriedades, como animais ou medidas de grão (Figura 3). Entre 4.0 e a.c., na cultura suméria, na Mesopotâmia (atual Iraque), surgiu a escrita baseada em pictogramas. 1 Figura 3 - Símbolos de contagem entalhados no período neolítico. Ao final do quarto milênio a.c., a cultura egípcia desenvolveu o conceito de som. Pictogramas hieróglifos representavam as sílabas. Os hieróglifos (Figura 4), porém, representavam apenas as consoantes, não as vogais. Eles eram utilizados para representar o primeiro som da palavra representada pelo pictograma, um conceito chamado acrofonia. O mesmo conceito pode ser encontrado na escrita fenícia, que influenciou a escrita hebraica, aramaica e grega. Já em 800 a.c., os gregos 6

11 MODELAGEM DE PROCESSOS foram os primeiros a representar as vogais com letras (Figura ), sendo os precursores do alfabeto romano, no qual boa parte dos países latinos baseou o seu alfabeto. Figura 4 - O hieróglifo egípcio. Figura - Os alfabetos fenício, grego antigo e romano. Fonte: Daun, DESENVOLVIMENTO DE SOFTWARES ORIENTADO A OBJETOS Este conceito tem sido discutido há muito tempo, desde o lançamento da 1ª linguagem orientada a objetos, a Simula. Vários autores da engenharia de software mundial, como Peter Coad, Edward Yourdon e Roger Pressman, abordaram extensamente a análise orientada a objetos como, realmente, um grande avanço no desenvolvimento de sistemas. Porém, eles citam que não existe uma linguagem que possibilite o desenvolvimento de qualquer software utilizando a análise orientada a objetos. Os conceitos que Coad, Yourdon, Pressman, e que tantos outros abordaram, discutiram e definiram em suas publicações foram que: 1 a orientação a objetos é uma tecnologia para a produção de modelos que especifiquem o domínio do problema de um sistema; 7

12 Unidade I quando construídos corretamente, sistemas orientados a objetos são flexíveis a mudanças, possuem estruturas bem conhecidas e provêm a oportunidade de criar e implementar componentes totalmente reutilizáveis; 1 modelos orientados a objetos são implementados convenientemente utilizando uma linguagem de programação orientada a objetos. A engenharia de software orientada a objetos é muito mais que utilizar mecanismos de sua linguagem de programação, é saber utilizar, da melhor forma possível, todas as técnicas da modelagem orientada a objetos; a orientação a objetos não é só teoria, mas uma tecnologia de eficiência e qualidade comprovadas, usadas em inúmeros projetos e para construção de diferentes tipos de sistemas; a orientação a objetos requer um método que integre o processo de desenvolvimento e a linguagem de modelagem com a construção de técnicas e ferramentas adequadas. 8