Análise Orientada A Objeto - Apostila

Anlise Orientada a Objeto um resumo consistente
Profa. Maria Cristina Basili Duarte
Anlise Orientada a Objeto Sumrio
1. Introduo ..................................................................................................... 2. Anlise Orientada a Objeto............................................................................ 3. Conceitos Fundamentais................................................................................ 3.1 Objeto....................................................................................................... 3.1.1 Identificao de objetos............................................................... 3.2 Atributos.................................................................................................. 3.2.1 Identificadores ou atributos determinantes.................................. 3.2.2 Descrio dos atributos................................................................ 3.2.3 Domnio....................................................................................... 3.2.4 Especificao de atributos........................................................... 3.3 Mensagem................................................................................................ 3.4 Abstrao................................................................................................. 3.5 Classe....................................................................................................... 3.6 Herana.................................................................................................... 3.6.1 Herana Simples.......................................................................... 3.6.2 Herana Mltipla......................................................................... 3.7 Encapsulamento....................................................................................... 3.8 Polimorfismo............................................................................................ 3.9 Mtodos.................................................................................................... 4. Use Cases (Caso de Uso)............................................................................... 4.1 Ator.......................................................................................................... 4.2 Caso de uso.............................................................................................. 4.3 Extenso................................................................................................... 5. Relacionamentos............................................................................................ 5.1 Conceito................................................................................................... 6. Diagramao.................................................................................................. 6.1 Diretrizes Bsicas..................................................................................... 6.2 Diagrama de Fluxo de Objetos (DFO)..................................................... 6.2.1 Objetivos...................................................................................... 6.2.2 Diretrizes...................................................................................... 6.2.3 Realidade e informao sobre a realidade.................................... 6.2.4 A funo de um processo............................................................. 6.2.5 DFD X DFO................................................................................. 6.2.5.1 Diagrama de Fluxo de Dados............................................... 6.2.5.2 Diagrama de Fluxo de Objetos............................................ 6.3 Diagrama de Eventos (DE)...................................................................... 6.3.1 Objetivos...................................................................................... 6.3.2 Diretrizes..................................................................................... 6.3.3 Fontes externas do Evento.......................................................... 6.3.4 Condies de Controle................................................................ 6.3.5 Eventos........................................................................................ 6.4 Diagrama de Objeto Relacionamento.................................................... 6.4.1 Objetivos..................................................................................... 6.4.2 Diretrizes..................................................................................... 6.4.3 Hierarquia de composio............................................................ 6.4.4 Restries de cardinalidade um para um.................................. 6.4.5 Restries de cardinalidade Zero.................................................
FACNET FAST - Anhanguera ii
01 02 03 03 03 04 05 05 05 05 06 06 06 07 07 08 08 09 09 10 10 10 10 11 11 11 11 12 12 12 12 14 14 14 14 15 15 15 15 17 17 18 18 18 18 19 20
Anlise Orientada a Objeto 20 22 23 23 24 24 25 25 25 26 26 26 26 27 27 27 27 28 28 28 29 29 30 30 30 31 31 31 32 32 32 33 35 35 36 36 37 37 38 38 38 40 40 42 44 45
6.4.6 Restries Mnimas e Mximas................................................... 6.4.7 Rotulando linhas.......................................................................... 6.4.8 Diagrama de objeto Relacionamento........................................... 6.4.9 Representao e ordenamento...................................................... 7. Metodologias de Anlise Orientada a Objeto................................................ 7.1 Introduo.............................................................................................. 7.2 Rumbaugh............................................................................................ 7.2.1 Conceitos....................................................................................... 7.2.2 Modelo de Objeto......................................................................... 7.2.3 Modelo funcional.......................................................................... 7.2.4 Modelo dinmico.......................................................................... 7.2.5 Regras........................................................................................... 7.2.6 Enquadramento conceitual........................................................... 7.2.7 Processos...................................................................................... 7.2.8 Anlise.......................................................................................... 7.2.9 Desenho do sistema...................................................................... 7.2.10 Desenho dos objetos..................................................................... 7.3 Booch.....................................................................................................
7.3.1 Conceitos......................................................................................
7.3.2 Diagrama de Classe...................................................................... 7.3.3 Diagrama de Transio de Estados.............................................. 7.3.4 Diagrama de Interao de Objetos............................................... 7.3.5 Enquadramento Conceitual.......................................................... 7.3.1.1 Anlise de requisitos.......................................................... 7.3.1.2 Anlise de domnio............................................................ 7.3.1.3 Desenho............................................................................. 7.3.6 Processos e Tcnicas................................................................... 7.3.7 Anlise de requisitos................................................................... 7.3.8 Anlise de domnio..................................................................... 7.3.9 Desenho....................................................................................... 7.4 Jacobson................................................................................................. 7.4.1 Conceitos...................................................................................... 7.4.2 Processos...................................................................................... 7.4.2.1 Anlise de requisitos......................................................... 7.4.2.2 Anlise de robustez........................................................... 7.4.2.3 Desenho............................................................................. 7.4.2.4 Implementao.................................................................. 7.4.2.5 Teste.................................................................................. 7.4.3 Tcnicas...................................................................................... 8. UML (Unified Modeling Language)............................................................. 8.1 Conceitos bsicos............................................................................... 8.2 Diagramas de Modelagem Dinmica................................................. 8.3 Diagrama de Seqncia...................................................................... 8.4 Diagrama de Estados.......................................................................... 8.5 Diagrama de Atividades..................................................................... 8.6 Estudo de Caso...................................................................................
9. O Papel do Modelo de Informao no desenvolvimento de Sistemas........... 46 9.1 Processo de desenvolvimento de Software ...................................... 47
FACNET FAST - Anhanguera iii
Anlise Orientada a Objeto 47 47 48 48 49 50 50 51 51 51 52 53 54 54 55 55 55 56 56 56 57 58
9.2 Fase de Anlise Uma abordagem Orientada a Objeto................... 9.2.1 Objeto e Modelagem de Informao..................................... 9.2.2 Estados dos Objetos e Modelo de Estado............................. 9.2.3 Atividade e Diagrama de Fluxo de dados............................. 9.2.4 Integrando os Modelos de Anlise........................................ 9.3 Fase de Especificao Externa.......................................................... 9.3.1 O que uma Especificao Externa...................................... 9.3.2 Expressar a Especificao definindo o limite....................... 9.3.2.1 Listas de Eventos........................................................... 9.3.2.2 Documentos narrativos dos requerimentos.................... 9.3.3 Determinando a Especificao por meio do que interno.... 9.3.4 Integrando a Fase de Especificao Externo......................... 9.4 Fase de projeto do Sistema............................................................... 9.4.1 Projeto de Arquitetura de Software....................................... 9.4.2 Sumrio da Fase de Projeto de Sistema................................. 9.5 Fase de Implementao.................................................................... 9.5.1 Coleta de dados...................................................................... 9.5.2 Projeto do Programa.............................................................. 9.5.3 Cdigo e Teste....................................................................... 9.5.4 Integrao e Aceitao........................................................... 9.5.5 O Papel do Modelo de Informao na Fase de Implementao............................................................................. Referncias Bibliogrficas...................................................................................
FACNET FAST - Anhanguera
iv
Anlise Orientada a Objeto
1. Introduo
O paradigma de desenvolvimento com orientao a objetos no novo. A programao orientada a objetos surgiu com a linguagem Simula em 1967. Porm, apenas na segunda metade da dcada de 80 (quase 20 anos depois), ela deixou de ser uma corrente marginal para tornar-se tema central de discusso em programao. Muito ajudou, nessa poca, o lanamento da linguagem C++, uma extenso orientada a objetos da linguagem C. Aproximadamente nessa mesma poca, comeou a vir luz a necessidade de contar com tcnicas que permitissem conduzir a fase anterior programao, o design, tambm de forma orientada a objetos. Em menos de 5 anos, j era evidente que a fase de anlise tambm deveria considerar, pelo menos parcialmente em um primeiro momento, os conceitos da orientao a objetos. Desta forma, a orientao a objetos, de maneira anloga dita "revoluo estruturada", completava seu desenvolvimento "reverso": da implementao para o design e da para a anlise. Na segunda metade dos anos 90, a Anlise Orientada a Objetos (AOO) est em uma etapa de consolidao. A situao atual da AOO, no que diz respeito a pesquisas acadmicas e aplicaes na rea industrial, pode ser descrita em termos de um conjunto de transformaes simultneas. Estas transformaes podem ser descritas sucintamente como segue: Existncia de muitas propostas alternativas para realizar a AOO. Inicialmente apresentadas na forma de artigos, agora a maioria descrita em livros. Esta grande diversidade pode parecer benfica, porm, muitas vezes, dificulta a escolha de alguma em particular e pode, inclusive, confundir na hora de definir quais os conceitos verdadeiramente relevantes neste tipo de anlise. Aproveitamento de idias, conceitos e representaes sugeridas pelas propostas pioneiras em AOO para configurar tcnicas denominadas de segunda gerao. Crescente interesse na possibilidade de padronizao e/ou convergncia das metodologias de AOO. Mudana na forma de conduzir a AOO, de uma estratgia dirigida por processos (usando, por exemplo, os DFD's da anlise estruturada) para uma estratgia dirigida por dados (usando os conceitos da modelagem semntica de dados) e, mais recentemente, para uma estratgia dirigida por comportamento (usando modelos de interao do sistema com agentes/sistemas/usurios externos). Relativa estabilidade nos conceitos mais importantes da modelagem do aspecto estrutural dos objetos. Isto foi possvel pela significativa contribuio da modelagem semntica de dados para este aspecto. Relativa instabilidade dos conceitos e modelos para o aspecto dinmico dos objetos. Existem diferentes consideraes sobre como abordar a dimenso do comportamento. Se a modelagem nesta dimenso feita antes, depois ou em paralelo com a da dimenso estrutural, qual(is) o(s) modelo(s) a ser(em) aplicado(s), como gerenciar a complexidade do comportamento do sistema, como distribuir o fluxo de controle entre os objetos etc.? Aumento da adoo pela indstria de metodologias orientadas a objetos que consideram a anlise, o design e a implementao ou, pelo menos, algumas destas fases. Aumento das opes de ferramentas CASE que introduzem, pelo menos parcialmente, os conceitos da orientao a objetos nas diversas fases do desenvolvimento de software. Veremos neste trabalho a Anlise Orientada a Objetos(AOO), suas caractersticas e informaes.
FACNET FAST - Anhanguera 1
2. Anlise Orientada a Objetos

A anlise orientada a objetos constituda de conceitos que so considerados inovadores comparados com os outros mtodos. Isto implica em uma mudana radical sobre as metodologias orientadas ao processo (como a anlise estruturada), porm, produzindo somente uma mudana incremental sobre as metodologias orientadas aos dados. De fato, seus conceitos podem parecer diferentes, porm eles so muito naturais e se aplicam ao nosso mundo real. O objetivo da anlise orientada a objetos o de desenvolver uma srie de modelos de anlise, satisfazendo um conjunto de requisitos definidos pelo cliente. Isto , esses modelos descrevem, de forma estruturada, as informaes, as funes e o comportamento de seus elementos constituintes. A informao (ou modelo de objeto) contm a definio dos objetos no sistema, os quais incluem: o nome do objeto, os atributos do objeto, e os relacionamentos que um objeto tem com outros. O modelo de comportamento(ou de estado) descreve o comportamento dos objetos em termos das transies permitidas entre os objetos e os eventos que causam a mudana de estado desses objetos.
(Estes modelos podem ser criados e mantidos usando ferramentas CASE que possibilitam a representao de objetos e seus respectivos comportamentos)
A AOO enxerga o mundo como objetos com estrutura de dados e comportamentos, e eventos que mudam estes comportamentos ou suas operaes. A idia que o sistema pode ser visto como uma populao de objetos interativos, cada um sendo um conjunto de dados e funcionalidades, o fundamento da tecnologia de objetos e fornece uma alternativa atraente para o desenvolvimento de sistemas complexos. Este um radical comeo comparado com os mtodos anteriores de especificao de requisitos, como a decomposio funcional e anlise estruturada. Uma grande variedade de mtodos de anlise orientada a objetos foram desenvolvidos desde 1988. Porm, todos eles possuem caractersticas comuns entre si, so elas: Representao de classes e hierarquias Criao de modelos de relacionamento de objetos Derivao de modelos de comportamento de objetos A AOO possui muitas vantagens, vejamos: Manutenibilidade atravs da simplificao do mapeamento do mundo real, o qual proporciona menos esforo de anlise, menos complexidade no design do sistema, e uma fcil verificao por parte do usurio Reusabilidade dos artifcios da anlise, os quais economizam tempo e custos Ganhos na produtividade atravs do direto mapeamento pelas caractersticas das Linguagens de Programao Orientadas a Objetos.
3. Conceitos Fundamentais
Vamos definir agora os principais conceitos que esto por trs da anlise orientada a objetos. Eles so de fundamental importncia para a anlise e, so eles que "fazem a diferena" com relao aos outros mtodos.
3.1 Objeto
A caracterstica bsica dos mtodos orientados a objeto a faanha de terem unificado os formalismo utilizados na anlise, projeto e programao Desde o momento que nossa mente nos habituou a pensar abstratamente, comeamos a formar conceitos sobre as coisas que nos cercam. Isto nos permitiu separar coisas semelhantes, segundo algumas caractersticas e atribuir um nome genrico ao conjunto. Por exemplo, um avio teco-teco, uma aeronave de carga, uma aeronave a jato; todas elas poderiam agrupar em um conjunto chamado Avio. Ou seja, o avio uma abstrao da realidade - trata-se de uma generalizao de um aspecto da realidade. Um objeto qualquer coisa, real ou abstrata, a respeito da qual armazenamos dados e os mtodos que os manipulam. entidade qualquer com identidade prpria que caracterizada por seu comportamentos (servios) e estados (atributos) Objeto uma representao abstrata de coisas do mundo real, que sob o ponto de vista do nosso problema, possuem atributos e mtodos comuns.
3.1.1 Identificao de Objetos

A identificao de objetos inicia-se ao examinar a declarao do problema ou ao executar uma "anlise gramatical" da narrativa de processamento do sistema a ser construdo. Objetos so determinados sublinhando-se cada nome ou clusula nominal e colocando-se numa tabela. Os objetos podem ser: Entidades Externas (por exemplo, outros sistemas, dispositivos, pessoas) que produzem ou consomem informaes a serem usadas por um sistema baseado em computador Coisas (por exemplo, relatrios, displays, cartas, cartazes) que fazem parte do domnio de informao do problema. Ocorrncias ou eventos (por exemplo, uma transferncia de propriedade ou a concluso de uma srie de movimentos de rob) que ocorrem dentro do contexto de operao do sistema. Papis (funes) (por exemplo, gerente, engenheiro, vendedor) desempenhados por pessoas que interagem com o sistema. Unidades Organizacionais (por exemplo, diviso, grupo, equipe) que so pertinentes a uma organizao. Lugares (por exemplo, piso de fbrica ou rea de descarga) que estabelecem o contexto do problema e a funo global do sistema. Estruturas (por exemplo, sensores, veculos de quatro rodas ou computadores) que definem uma classe de objetos ou, ao extremo, classes relacionadas de objetos.
Os objetos podem ser definidos durante os primeiros estgios de anlise, atravs da anlise gramatical da narrativa de processamento. Extraindo os nomes, que sero as entradas na lista, estamos definindo os Objetos em Potencial dessa lista. Caractersticas de seleo que devem ser usadas ao se examinar cada objeto em potencial para incluso no modelo de anlise: Informao Repetida: O objeto em potencial ser til durante a anlise somente se a informao sobre ele precisar ser lembrada de forma que o sistema possa funcionar. Servios Necessrios: O objeto em potencial deve ter um conjunto de operaes identificveis que podem mudar o valor de seus atributos de alguma forma. Mltiplos Atributos: Durante a anlise de requisitos, o foco deve recair sobre informaes importantes; um objeto com um nico atributo pode, de fato, ser til durante a fase de projeto, mas provavelmente ele ser mais bem representado como um atributo de outro objeto durante a atividade de anlise. Atributos Comuns: Um conjunto de atributos pode ser definido para o objeto em potencial, e esses atributos aplicam-se a todas as ocorrncias do objeto. Operaes Comuns: Um conjunto de operaes pode ser definido para o objeto em potencial, e essas operaes aplicam-se a todas as ocorrncias do objeto. Requisitos Essenciais: Entidades externas que aparecem no espao problema e produzem ou consomem informaes que so essenciais operao de qualquer soluo para o sistema quase sempre sero definidas como objetos no modelo de requisitos. A deciso de incluso de objetos em potencial no modelo de anlise um tanto subjetiva, e uma avaliao posterior pode fazer com que o objeto seja descartado ou reconsiderado.
1. Os objetos tambm apresentam algumas propriedades: Estado Diz respeito situao em que pode estar um determinado objeto. Por exemplo, o objeto caneta, pode estar no estado, com tinta ou sem tinta. Podemos ainda atribuir a caneta outros estados inteira para uso ou quebrada. O estado depende da natureza do objeto. Comportamento Qualquer objeto apresenta um comportamento. O comportamento o meio atravs do qual o objeto passa de um estado para outro. Normalmente isto d mediante uma condio/ao (a ao ser sempre um mtodo a ser executado) Identificao Todo objeto identificvel. Embora se possam ter vrias canetas de um mesmo tamanho, cor, fabricante e modelo, cada uma delas uma caneta em particular, tem sua prpria identidade, so, portanto distinguveis entre si.
2.
3.
3.2 Atributos
Um atributo a abstrao de uma nica caracterstica possuda pelas entidades que foram abstradas com um objeto. O Objetivo Obter um conjunto de atributos que sejam: Completos - eles abrangem todas as informaes pertinentes ao objeto que esta sendo definido; Totalmente fatorados Cada atributo capta um aspecto separado da abstrao do objeto; Mutuamente independentes os atributos assumem seus valores ficando independentes uns dos outros. Os atributos podem ser identificados fazendo referncia: s caractersticas das instncias do objeto
descrio do objeto: que informaes precisaramos conhecer a propsito de uma entidade para dizer que uma instncia deste objeto?
Os atributos que voc identificar cairo dentro de trs categorias, relacionadas abaixo, dependendo da espcie de informao captada por cada um deles: Atributos descritivos caractersticas intrnsecas ao objeto Atributos nominativos nomes e rtulos arbitrrios Atributos referenciais fatos que ligam uma instncia de um objeto a uma instncia de outro objeto.
3.2.1 Identificadores ou atributos determinantes

Um conjunto de um ou mais atributos que singularmente distingue cada exemplo de um objeto um identificador para aquele objeto. Um identificador s vezes chamado de chave candidata. Devem obedecer as seguintes restries: No h outra entidade com o mesmo valor para o atributo O atributo no nulo para nenhuma entidade se no houver, naturalmente, um atributo que satisfaa.
3.2.2 Descrio dos atributos

A descrio do atributo um breve relato informativo que descreve de que maneira o atributo formal reflete as caractersticas de interesse do mundo real. Esta descrio do atributo requerida para cada atributo presente no modelo.
3.2.3 Domnios
O conjunto de valores que um atributo pode assumir constitui o seu domnio
3.2.4 Especificao de Atributos

Os atributos descrevem um objeto que foi selecionado para incluso no modelo de anlise. Fundamentalmente, so os atributos que definem o objeto - que esclarecem aquilo que o objeto significa no contexto do espao do problema. Para desenvolver um conjunto de atributos significativo para um objeto, o analista pode estudar mais uma vez a narrativa de processamento do problema e selecionar aqueles aspectos que, razoavelmente, "pertenam ao objeto". Alm disso, a seguinte pergunta deve ser respondida em relao a cada objeto: quais itens de dados definem plenamente esse objeto no contexto do problema que se tem frente?
3.3 Mensagem
Definir objetos dentro do contexto de um modelo de anlise pode ser o bastante para lanar as bases para o projeto. Mas algo mais precisa ser acrescentado para que o sistema
possa ser construdo - um mecanismo de comunicao deve ser estabelecido entre os objetos. Esse mecanismo denominado mensagem As interaes entre os objetos so feitas atravs de mensagens: Solicitaes para que um objeto faa algo, isto , para que uma operao seja ativada. As mensagens que o objeto recebe so os nicos elementos que conectam o objeto ao mundo exterior. A comunicao da mensagem importante para a implementao de um sistema orientado a objeto, mas ela no precisa ser considerada detalhadamente durante a anlise de requisitos. De fato, a nossa nica preocupao nessa fase usar o conceito para ajudar a determinar as possveis operaes para um objeto especfico. Um protocolo de passagem de mensagens envolve fundamentalmente duas partes: um emissor e um receptor. Quando o emissor envia uma mensagem para certo receptor ele deve especificar o seguinte: 1. um receptor, 2. uma requisio de servio, e 3. argumentos ou parmetros (se necessrio) Inicialmente o objeto receptor deve ser especificado. Uma vez ativado o receptor verifica se o servio solicitado pode ser atendido. Caso no possa, o emissor notificado e o receptor no realiza processamento algum. Em caso positivo, o receptor aceita e responde a mensagem ativando o mtodo correspondente.
3.4 Abstrao
Abstrao o processo atravs dos quais detalhes so ignorados para nos concentrarmos nas caractersticas essenciais. A abstrao nos leva a representar os mdulos em um nvel mais elevado, fazendo com que os detalhes fiquem ocultos no interior do mdulo. Para descrevermos um automvel, do ponto de vista de um observador externo, identificamos sua cor, o n de portas e pneus. Quando identificamos o automvel a partir destas caractersticas externas estamos fazendo uma abstrao, pois uma srie de detalhes internos no estar sendo descritos. A abstrao na descrio de objetos depende do ponto de vista e objetivo de quem faz a descrio; Se solicitarmos a um mecnico para fazer a descrio de um automvel a partir de seu ponto de vista, teremos um resultado bem diferente da descrio de um condutor comum.
3.5 Classe
Uma classe de objetos representada um conjunto de objetos de mesmas caractersticas. Suponha existir uma classe de objetos avio. Ela ser uma generalizao de objeto avio. Todos os objetos desta classe tero identidade e sero distinguveis. Dois avies da
mesma cor, tamanho e formato continuaram sendo avies distintos. Cada um deles uma instncia de objeto, dado a sua existncia so diferenciados por sua identidade. Uma instncia herda as caractersticas da classe a que pertence (por caractersticas entendem-se os atributos e mtodos). Pode ocorrer tambm a existncia de uma Classe de Classe. Neste caso temos uma generalizao de classe. Toda classe de classe chamada de Metaclasse, ou Super-Classe. Toda classe que herda as caractersticas de outra classe, pode ser chamada de subclasse FACNET FAST - Anhanguera
Atravs dos relacionamentos de generalizao / especializao as classes so organizadas em hierarquias com base em suas similaridades e diferenas. As classes podem possuir subclasses (classes derivadas).
As classes mais altas na hierarquia so denominadas superclasses.
Pessoa
Cliente
Empregado
Acionista
Vnculo Empregatcio
Autnomo
Gerente
No Gerente
3.6 Herana
Herana pode ser classificada como o relacionamento entre classes onde uma classe compartilha a estrutura e o comportamento j definidos em uma (herana simples) ou vrias (herana mltipla) classes. A herana define uma hierarquia entre classes, na qual uma subclasse herda de uma ou mais superclasses. Benefcios da herana. Poderoso instrumento de reusabilidade e produtividade, pois: atributos e operaes comuns especificados apenas uma vez; novas classes so facilmente criadas (apenas a diferena entre ela e a classe-pai). Uma classe implementa o tipo de objeto. Um a subclasse herda as propriedades de sua classe me; uma subclasse herda as propriedades das subclasses e assim por diante. Uma classe pode herdar a estrutura de dados e os mtodos, ou alguns dos mtodos, de sua superclasse. Elas tambm tm mtodos e, s vezes, tipos de dados prprios. Tipos: Herana simples Herana mltipla
3.6.1 Herana simples

Processo pelo qual uma classe derivada herda os atributos e mtodos de outra classe, denominada classe base. Exemplo: Empregado Empregado Chapa: Chapa: Nome: Nome: Atributos Profisso: Atributos Profisso:
Anlise Orientada a Objeto especficos Data admisso: Salrio Bruto: Previdncia Mtodo Calcula salrio lquido especfico Calcula previdncia
Data admisso: Salrio Bruto: Mtodos Calcula salrio lquido
3.6.2 Herana mltipla

Processo pelo qual uma classe (denominada classe derivada) herda atributos e servios de mais de uma classe base. Exemplo: Empregado Empregado
Atributos
Mtodos
Chapa: Nome: Profisso: Data admisso: Salrio Bruto: Calcula salrio lquido
Nmero: Validade: Salrio Contratual:
Atributos
Calcula tempo de casa
Mtodos
Empregado Estagirio
Atributos
Mtodos
Chapa: Nome: Profisso: Data admisso: Salrio Bruto: Tempo de casa: Nmero do contrato: Validade do contrato: Calcula salrio lquido
8
Calcula tempo de casa
3.7 Encapsulamento
Encapsulamento a ocultao ou empacotamento de dados procedimentos dentro do objeto. Um objeto s permite o acesso a seus dados, mediante o acionamento de seus mtodos, atravs de uma mensagem, para a qual, pode devolver uma resposta. O encapsulamento oculta os detalhes de sua implementao interna aos usurios de um objeto. Os usurios entendem quais operaes do objeto podem ser solicitadas, mas no conhecem os detalhes de como a operao executada. Todos os aspectos especficos dos dados do objeto e da codificao de suas operaes so mantidos fora de visita. Note, contudo, que a estrutura interna do videocassete est protegida por uma carcaa. Este encapsulamento previne manipulaes incorretas do equipamento, propiciando uma maior garantia da integridade interna do videocassete. Desde que o lacre de garantia no seja rompido, o fabricante garante seu correto funcionamento em condies normais de uso. Este encapsulamento induz, tambm, certo ocultamente da estrutura interna do videocassete. Em realidade boa parte dos usurios no faz idia de como realmente um videocassete ou de quais so os processos que esto envolvidos quando da reproduo de uma fita. Mas isto no os impede de utilizar o equipamento em sua plena funcionalidade, bastando apenas que ele saiba interagir com sua interface externa (botes e etc.). O conhecimento da estrutura interna s se faz necessrio quando se for proceder a reparos, ou nos casos em que explicitamente se deseje desvendar o equipamento. Este mecanismo de encapsulamento e ocultamento da estrutura interna bastante comum. Veja exemplos como: as cascas das frutas e dos ovos, a lataria de um carro, a pele dos animais, a roupa dos astronautas, etc.
3.8 Polimorfismo
Mensagens iguais, destinadas a objetos diferentes, podem gerar comportamento diferentes. Para uma mesma mensagem, objetos diferentes podem responder ou agir de forma diferenciada; a isto, chamamos polimorfismo. Por exemplo, uma mensagem print para uma impressora, pode fazer com que a mesma imediatamente, comece a imprimir. A mesma mensagem para outra impressora pode ocasionar a apresentao de uma tela com opes de configurao da impressora. Portanto temos a mesma mensagem enviada para objetos distintos os quais responderam de forma diferenciada.
3.9 Mtodos
Os mtodos descrevem os possveis comportamentos associados a um objeto. Representam a ao que pode ser executada por um objeto ou sobre um objeto. O desempenho de um comportamento pode resultar na modificao de valores dos atributos do objeto. Assim a execuo de um mtodo pode conduzir a uma transformao nos dados locais do objeto, podendo ser vista como um processo de transformao entre dois estados. Cada
mtodo possui um nome e um corpo que desempenha a ao ou comportamento associado ao nome do mtodo. Em linguagens orientadas a objetos o corpo de um mtodo consiste em um conjunto de procedimentos que executam a ao solicitada. Esta ao pode possuir efeitos colaterais. Todos os mtodos que acessam ou alteram os dados locais em um objeto devem ser especificados no prprio objeto. Um mtodo em um objeto pode ser ativado por meio de uma mensagem vinda de outro objeto, ou por outro mtodo no mesmo objeto por meio de uma mensagem local de um mtodo para outro no mesmo objeto. Um mtodo associado ao tipo de objeto Fatura poderia ser um que computasse o total de uma fatura e outro que transmitisse a fatura a um cliente. Ainda outro poderia verificar periodicamente se a fatura foi paga e adicionar juros a ela, caso no tenha sido paga.
4. Use Cases (Casos de Uso)

Modelo que especifica a funcionalidade que o sistema tem a oferecer da perspectiva do usurio. Utiliza: atores: papis a serem desempenhados pelos usurios; casos de uso: o que os usurios esto aptos a fazer com o sistema.
4.1 Ator
uma categoria de usurios. Modela qualquer coisa que necessite trocar informaes com o sistema, como seres humanos, outros sistemas, dispositivos, etc. Sempre externo ao sistema. Atores sero: primrios: usaro o sistema diretamente. A funcionalidade principal definida por eles, o que direcionar a estrutura do sistema; secundrios: que supervisionam e mantm o sistema. Existem apenas para que os atores primrios possam utilizar o sistema.
4.2 Caso de uso

um modo especfico de utilizao do sistema pela execuo de alguma parte de sua funcionalidade. Cada caso de uso constitui em um curso completo de eventos, iniciado por um ator, e especifica a interao entre o ator e o sistema. Os atores so identificados inicialmente, pois a maior ferramenta para encontrar casos de uso. Algumas perguntas que auxiliam: quais so as principais tarefas de cada ator? o ator ter que ler/gravar/alterar qualquer informao do sistema? o ator ter que informar ao sistema sobre mudanas externas? o ator deve ser informado sobre mudanas inesperadas? Um caso de uso ter: curso bsico: mais importante e representativo curso de eventos;
cursos alternativos: variantes do curso bsico e erros.
4.3 Extenso
um caso de uso que estende outro caso de uso (principal). So utilizados para modelar: partes opcionais de casos de uso; cursos complexos e alternativos que raramente ocorrem; sub-cursos separados que ocorrem em casos especiais; Situaes onde vrios diferentes casos de uso podem ser inseridos em um caso de uso especial. Para que seja inserido, deve haver um ponto de insero no caso de uso original, porm que ser expresso apenas na descrio da extenso.
5. Relacionamentos
5.1 Conceito de Relacionamento
Um relacionamento uma abstrao de um conjunto de associaes que subsiste sistematicamente entre espcies diferentes de coisas do mundo real. Relacionamentos so associaes entre duas ou mais entidades. Um relacionamento descreve um tipo especfico de associaes entre os conjuntos de entidades participantes. Cada tipo de associao deve ser descrita por um relacionamento diferente. Uma ocorrncia de um relacionamento liga ocorrncias especficas das entidades participantes. Veremos com mais detalhe no Diagrama de Objeto Relacionamento. (DOR) na pgina (18).
6. Diagramao
6.1 Diretrizes Bsicas
Deve-se enfatizar o envolvimento do usurio final. Os modelos baseados em objetos tm que ser de fcil compreenso para o usurio. Os diagramas baseados em objetos devem ser executveis
Quando dizemos que um diagrama executvel, queremos dizer que o cdigo pode ser gerado a partir dele. Para que isso seja possvel preciso que o diagrama seja rigoroso e preciso. O cdigo deve ser gerado, to imediatamente quanto possvel, e testado, a partir dos diagramas, o que facilita o reprojetar iterativo. As tcnicas baseadas em objeto devem facilitar o processo de reprojetar a empresa. Os modelos corporativos devem ser "inteligentes". As tcnicas baseadas em objetos devem ser to automatizadas quanto possvel. Desenvolvimento baseado em objetos necessita de padres de diagramao.
11
Os padres de diagramao baseados devem ser to fceis de serem aprendidos quanto possvel pelo pessoal de sistemas convencionais. Necessita-se de um repositrio para a anlise e o projeto baseados em objetos.
O princpio da navalha de Occam deve ser aplicado aos tipos de objeto William de Occam, um filsofo do sculo XIV, declarou que, ao fatiar o mundo em categorias voc no deveria multiplicar as entidades desnecessariamente (o princpio da navalha de Occam). Um princpio semelhante se aplica anlise baseada em objeto: minimizar o nmero de tipos de objeto. Um pequeno nmero de tipos de objetos de alto nvel tem subtipos que herdam as propriedades de seus pais. Os subtipos tm seus subtipos, e assim por diante. Se modelarmos a empresa com uma quantidade mnima de cdigo para gerar e manter. Uma anlise de alto nvel faz-se essencial. Muito do trabalho j realizado sobre tcnicas baseadas em objetos refere-se programao, lamentavelmente, muito menor ateno tem sido dispensada a anlise. A maior parte dos benefcios e do retorno financeiro das tcnicas baseadas em objetos ocorre quando a anlise realmente bem-feita. Uma anlise completa de toda a empresa faz-se necessria O mximo de benefcio alcanado quando a anlise feita atravs de toda empresa. Isso feito com engenharia da informao baseada em objetos. Principais Ferramentas Diagrama de Fluxo de Objetos. (DFO) Diagrama de Eventos. (DE) Diagrama de Objeto Relacionamento. (DOR)
6.2 Diagrama de Fluxo de Objetos. (DFO)

6.2.1 Objetivos:
Mostrar uma viso geral do funcionamento do sistema, Permitir a verificao da abrangncia do sistema, Demonstrar como o sistema interage com o meio ambiente, constituir uma base de dilogo e levantamento de dados com os usurios.
6.2.2 Diretrizes:
Ser de fcil entendimento, Demonstrar todo o sistema e todos os objetos que interagem com ele, Utilizar sempre o princpio da navalha de Occam. No se ater a detalhes do funcionamento, Participao do usurio.
12
6.2.3 Realidade e Informao Sobre e Realidade

A maioria dos blocos dos diagramas CASE representa como o computador reflete a realidade. Eles so desenhados na forma de caixas ou smbolos bidimensionais. Porm, alguns blocos dos diagramas CASE representam a realidade em si. Eles poderiam, por exemplo, representar um objeto fsico movendo-se de um processo para outro. So desenhados na forma de caixas ou outras figuras tridimensionais. Um tipo de objeto, ou uma instncia de um tipo de objeto armazenado no computador, desenhado na forma de um retngulo. Porm, em diagramas de fluxo de objetos, o objeto uma coisa fsica, como um produto, em vez de uma representao simblica num computador. O objeto fsico pode ser desenhado como uma caixa tridimensional:
Objetos e Operaes Externas

Outras figuras tridimensionais tambm podem ser usadas para representar objetos: Os diagramas representaram a maioria do que acontece num sistema ou coleo de sistema. s vezes, um objeto ou uma operao so externos ao sistema, mas acabam por afet-lo. Objetos e operaes externas so desenhados como caixas sombreadas: Um diagrama de fluxo de objetos pode mostrar operaes, objetos fsicos reais (tridimensionais) e objetos externos no mesmo diagrama.
6.2.4 A Funo de Um Processo

Conforme j foi declarado, o analista OO precisa de um mtodo para analisar processos complicados, tais como empresas e grandes organizaes, em termos de como elas funcionam. Aqui, uma funo empresarial refere-se ao propsito de um processo. Essa funo ou propsito, ento, determina as atividades essenciais que administram as operaes e recursos de uma organizao. Como tal, os modelos de nvel estratgicos no especificam a dinmica. Eles no indicam quando as atividades sero ativadas ou encerradas. Os modelos de nvel estratgico descrevem as interaes entre os processos.
6.2.5 DFD X DFO 6.2.5.1 Diagramas de Fluxo De Dados

Uma maneira de se modelar em nvel estratgico com diagrama de fluxo de dados (DFDs). Os DFDs descrevem prontamente o sentido de decomposio e fluxo de informaes de modelo de nvel estratgico. Por exemplo, os dados podem fluir sem necessariamente definir se ou quando fluiro, quo freqentemente fluiro e se fluxo ser iniciado pela atividade anterior ou solicitado pela ltima.
14
Em outras palavras, a abordagem de nvel estratgico descreve o possvel fluxo de informaes e decomposio de atividades. Porm, ela nada indica sobre como essas atividades e seus inputs e outputs so controlados.
6.2.5.2 Diagramas de Fluxo De Objetos

Em vez de se limitarem apenas aos dados que fluem, os modelos de nvel estratgico OO indicam qualquer tipo de objeto que flua entre as atividades. Dessa maneira, tal abordagem pertinente anlise orientada a objeto. O modelo de nvel estratgico apresentado denominado diagrama de fluxo de objetos. Os diagramas de fluxo de objetos empregam uma abordagem do nvel estratgico que orientada a objeto. Adicionalmente, eles representam as exigncias de processamento de uma maneira que os planejadores de negcio possam entender e aplicar a projetos de planejamento estratgico - no apenas a projetos de sistema de informaes.
Os diagramas de fluxo de objetos representam as atividades empresrias chave ligada pelos produtos que as atividades produzem e trocam.
6.3 Diagrama de Eventos. (DE)

6.3.1 Objetivos:
Detalhar o funcionamento do sistema, Mostrar os eventos e as operaes desencadeadas por eles, Demonstrar a seqncia das operaes. Constituir uma base de dialogo e levantamento de dados com os usurios
6.3.2 Diretrizes:
Ser de fcil entendimento, Detalhar as operaes e os eventos vinculados a elas, Utilizar sempre o principio da navalha de Occam, Participao do usurio, dentro do possvel.
6.3.3 Fontes Externas de Eventos

Eventos so mudanas de estado que um sistema deve conhecer e aos quais de reagir. Freqentemente, muitas das operaes que causam esses eventos so externas ao sistema. Em tais circunstncias, o smbolo de operao desenhado como um retngulo sombreado com cantos arredondados, conforme ilustra a Figura 7.9(a). O desenho de um relgio externo uma forma especial de representar uma fonte externa. Ele indica que um processo externo emitir tempos de relgio em alguma freqncia anteriormente especificada, como, por exemplo, a cada segundo, ao final de cada dia, no comeo de cada ms ou no dia 15 de abril de cada ano. O evento, ento, ocorre em funo da freqncia indicia pelo relgio externo. Os relgios externos so representados como mostradores de relgio. A figura 7.8 contm dois eventos externos resultantes de uma operao externa.
16
6.3.4 Condies de Controle

Conforme foi descrito anteriormente, uma operao pode ser invocada por um ou mais gatilhos. Por exemplo, na Figura 7.8, a operao FECHAR PEDIDO gatilhada quando quer que um evento PEDIDO EXPEDIDO ou FATURA PAGA ocorra. Porm, antes que a operao seja de fato invocada, sua condio de controle verificada. Se os resultados da avaliao da condio forem verdadeiros, sua operao invocada. Se forem falsos, a operao no invocada. Sempre que uma condio de controle precisar ser verificada antes de invocar uma operao, ela deve ser representada por um smbolo em forma de losango precedendo a operao:
As condies de controle tambm podem agir como pontos de sincronizao para processamento paralelo. Em outras palavras, as condies de controle podem garantir que um conjunto de eventos esteja completo antes de prosseguir com uma operao. A condio de controle da Figura 7.8, por exemplo, poderia declarar que um objeto PEDIDO no pode ser
classificado como PEDIDO FECHADO a menos que ele tenha sido expedido e sua fatura paga.
6.3.5 Eventos
Operaes so processos que podem ser solicitados como unidades. Quando as operaes so bem-sucedidas, ocorrem eventos. As operaes e os eventos esto, dessa forma, estreitamente ligados. Um tipo de evento pode ser representado por um tringulo cheio no incio de uma linha que sai da caixa de processo. O tringulo escolhido porque ele "aponta" para o momento em que ocorre uma mudana de estado do objeto como resultado da operao precedente.
A linha que sai da caixa de operao serve como uma representao conjunta do tipo de evento e do gatilho. A colocao de um pequeno tringulo cheio no incio da linha constitui um lugar em que um clique de mouse pode ser dado para se olharem os detalhes do tipo de evento ou as ps-condies da operao.
6.4 Diagrama de Objeto Relacionamento. (DOR)

6.4.1 Objetivos:
Demonstrar os relacionamentos, herana e as composies existentes entre os tipos de objetos (classes), de todo o sistema.
6.4.2 Diretrizes:
Representar os relacionamentos, heranas (generalizao) e as composies, evitar diagramas que ultrapassem uma pagina, Utilizar sempre o principio da navalha de Occam.
6.4.3 Hierarquias de Composio

Alguns tipos de objetos so descritos como complexos. Por complexo queremos dizer que alguns objetos so percebidos como sendo compostos de outros. Por exemplo, um carro pode ser descrito como consistindo em um chassi, rodas e um motor. Por sua vez, o motor
composto de um bloco do motor, vlvulas, pistes e assim por diante. Adicionalmente, o pisto um objeto complexo composto de anis, uma biela e cabea do pisto. para os interessados, esse processo pode continuar at descrever por fim as partculas atmicas e subatmicas de cada pea do carro. Na anlise OO, a decomposio do objeto ajuda a descrever que os projetos so compostos de certa configurao de smbolos, que os trabalhos so compostos de tarefas especficas, que as organizaes consistem em outras organizaes. Em sistemas de tecnologia avanada, o analista descrever como um pedido pode consistir no apenas em itens de linha, mas tambm de instrues verbais do cliente e tambm de um diagrama feito a mo. Pedidos desse tipo so denominados objetos complexos. Cada pedido pode ser manipulado como um nico objeto consistindo em outros objetos que, por sua vez, podem ser manipulados separadamente, se necessrio. Uma maneira de representar o aspecto "composto de" de objetos por meio de diagramas, como mostra a Figura 6.8.
6.4.4 Restries de Cardinalidade "Um para Um"

Em diagramas que usam restries de cardinalidade, a cardinalidade "um para um" desenhada com uma pequena barra ao longo da linha (parecendo um smbolo "1").
19
6.4.5 Restries de Cardinalidade Zero

Um zero como parte do smbolo de restrio cardinalidade significa que uma instncia de um tipo de objeto no est associada a quaisquer instncias de outra. Isto , um objeto de um tipo pode ter zero associaes com os objetos de outro tipo:
Em esquemas de objetos, porm, uma linha representando uma associao entre tipos de objetos sempre deve ter um smbolo de restrio cardinalidade em ambas as extremidades. No boa prtica de anlise desenhar uma linha conectando um retngulo de tipo de objeto sem nenhum smbolo de restrio cardinalidade.
6.4.6 Restries Mnimas e Mximas

Os smbolos de cardinalidade expressam uma restrio mxima e mnima:
20
A mxima sempre colocada prximo caixa qual ela se refere. Onde a mnima e a mxima so ambas iguais a 1, duas barras 1 so colocadas na linha. As duas barras significam "uma e somente uma":
A figura 9.6 resume a representao das restries mximas e mnimas cardinalidade.
A figura 9.7 descreve quatro tipos de objeto com associaes entre os tipos. Ela expressa da mesma maneira que um diagrama de entidade - relacionamento.
s vezes, a cardinalidade no pode ser expressa em termos de zero, uma ou muitas. Por exemplo, um Encontro exige no mnimo duas Pessoas. Aqui, a cardinalidade mnima dois. Alm disso, uma organizao pode colocar a restrio de que um encontro no pode ter mais de 20 pessoas participando dele. Isso expresso enumerando-se a restrio cardinalidade:
6.4.7 Rotulando as Linhas

Em alguns tipos de diagramas, as linhas que conectam ns devem ser rotuladas. As linhas entre tipos de eventos e operaes so unidirecionais. As linhas entre as caixas de tipos de objeto, por outro lado, usualmente so bidirecionais. A linha pode ser lida em qualquer direo.
22
Basta rotular as linhas numa direo, no obstante seja recomendada a rotulao de todas as associaes entre os tipos de objetos. Um rtulo acima de uma linha horizontal o nome da associao quando lido da esquerda para a direita. Um rtulo abaixo de uma linha horizontal o nome quando lido da direita para a esquerda. Quando a linha girada, o rtulo permanece no mesmo lado da linha:
6.4.8 Diagrama de objeto relacionamento

Os diagramas de entidade - relacionamentos so de uso comum na anlise no OO. Os diagramas de objeto - relacionamento so semelhantes. Eles mostram que um tipo de objeto associado a outros tipos de objeto. Por exemplo, na figura 9.15, um Empregado trabalha num local; um Cliente faz Pedidos; um pedido refere-se a certos Produtos.
6.4.9 Representaes de Ordenamento

As funes podem associar objetos de um tipo de objeto com objetos do mesmo tipo de objeto. Elas so chamadas funes de ordenamento. Por exemplo, a figura 19.9 representa duas maneiras de expressar o ordenamento de uma hierarquia administrativa. Ambas as notaes so equivalentes.
23
7. Metodologias de Anlise Orientada a Objeto

7.1 Introduo
Para fazer um estudo das metodologias OO, necessrio conhecer as pessoas que esto por trs desta comunidade, pois l, existe uma grande diversidade de idias. Muitas destas pessoas discutem as suas opinies apenas em termos da sintaxe e semntica das linguagens de programao por eles selecionadas. So utilizados os termos anlise e desenho de uma forma bastante informal. Anlise pode significar ouvir os clientes, tomar algumas notas e apontamentos, pensar acerca do problema e das potenciais solues, e construir alguns prottipos de software. Desenho pode significar a codificao dos objetos individuais, o desenvolvimento de uma hierarquia de objetos ou a definio informal e implementao de uma determinada classe. Existe outro grupo de pessoas que est interessada na formalidade e no rigor. Para estas pessoas, a engenharia de software altamente sistemtica e repetvel. Eles vem a engenharia de software OO como um processo de engenharia muito bem definido. A qualidade dos produtos resultantes pode ser avaliada de uma forma quantitativa, bem como qualitativa. Assim, a avaliao e comparao deste tipo de metodologias uma atividade difcil e complexa. Enquanto que esta diferena em termos de terminologia pode parecer puramente acadmica, a aplicao destes mtodos significativamente influenciada por esta distino. A completa especificao das vrias metodologias varia dramaticamente. Por exemplo, alguns descrevem apenas o processo, outros apresentam uma notao grfica, enquanto que outros combinam as notaes com o processo. Sem compreender a cultura que est por trs de uma determinada metodologia, impossvel efetuar uma correta avaliao e comparao. Para tentar passar, de uma forma mais ampla e genrica, o conceito de O.O. na anlise de sistemas, foram escolhidos trs mtodos que me parecem os mais significativos em termos de aplicao, bem como divulgao. No se trata de uma exposio exaustiva dos referidos mtodos, mas sim, de uma descrio dos conceitos, processos, tcnicas e ferramentas de suporte utilizadas em cada um dos mtodos, de forma a ser possvel encontrar semelhanas e diferenas, bem como problemas subjacentes. Assim, so apresentados trs das principais abordagens atuais:
1. Rumbaugh 2. Booch 3. Jacobson
7.2 Rumbaugh.
Este mtodo, denominado OMT-Object Modeling Technique, tem um carter amplo em termos de domnio de alcance, no incluindo a modelao estratgica. Este mtodo encontra-se dividido em quatro fases: 1. Anlise; 2. Desenho do sistema; 3. Desenho dos objetos; 4. Implementao; Aqui, considerada uma grande distino entre anlise e desenho. O modelo de anlise segmentado em trs sub-modelos: 1. Modelo de objetos; 2. Modelo dinmico; 3. Modelo funcional; Os diagramas de estado do modelo dinmico e do modelo de objetos so notveis pela sua riqueza semntica. Na fase de desenho, os esforos so concentrados exclusivamente na arquitetura global do sistema, concentrando-se na otimizao e refinamento do modelo de objetos, preparando-o para a transformao numa linguagem de programao. dada pouca importncia ao desenvolvimento da interface homem-mquina, embora os dilogos com o utilizador denominados cenrios representem uma importante tcnica de anlise nesta rea. Diferentemente de outros mtodos, o OMT no d grande ateno ao comportamento do sistema em questo, como forma de descoberta e clarificao das hierarquias de classes existentes. OMT foi aplicado inicialmente com o intuito de desenvolvimento de sistemas de tempo real e sistemas especficos, como compiladores, interfaces grficas e bases de dados, podendo, no entanto, ser aplicado ao desenvolvimento de sistemas de informao.
7.2.1 Conceitos.
Este mtodo suporta os paradigmas bsicos dos objetos, como seja: abstrao, encapsulamento e herana. O conceito de mensagem no predominante, sendo o estado, transio e evento largamente explorado no modelo dinmico. Cobre, no entanto, alguns conceitos menos freqentemente utilizados por outros mtodos, que sero mostrados de seguida.
7.2.2 Modelo de objetos.

Em relao aos conceitos associados com o modelo de objetos, destacam-se os seguintes: Qualified association - Associao binria entre classes, em que a primeira componente um conjunto de classes agregadas e a segunda componente uma classe;
Non-disjoint subclasses - Significa que as subclasses se sobrepem nos membros constituintes; Module - Subconjunto coerente de um sistema contendo um grupo de classes relacionadas;
7.2.3 Modelo funcional.

Em relao aos conceitos associados com o modelo funcional, destacam-se os seguintes: Actor object - Objeto ativo que atua sobre o diagrama de fluxo de dados, produzindo ou consumindo dados; Process - Algo que transforma os valores dos dados; Data flow - Ligao entre o output de um objeto ou processo e o input de outro; Control flow - Valor booleano que afeta um processo em execuo;
7.2.4 Modelo dinmico.

Em relao aos conceitos associados com o modelo dinmico, destacam-se os seguintes: Action - Operao instantnea associada com um evento; Activity - Operao que demora algum tempo a ser concluda, estando associada com um estado e representando um fato do mundo real. Condition - Funo booleana dos valores de um objeto vlida durante um intervalo de tempo; Guard condition - Expresso booleana que deve ser verdadeira de forma a ocorrer uma determinada transio;
7.2.5 Regras.
Em relao aos conceitos associados com as regras, destacam-se os seguintes: Constraint - Relao funcional entre objetos, classes, atributos, ligaes e associaes, que deve ser mantida verdadeira. Assertion - Declarao acerca de uma condio ou relacionamento que deve ser verdadeira ou falsa na altura em que testada; Invariant - Declarao sobre uma condio ou relacionamento que deve ser sempre verdadeira;
7.2.6 Enquadramento Conceitual.

A fase de anlise consiste no seguinte: 1. Definio do problema;
2. Modelo de objetos, constitudo pelos diagrama de objetos e dicionrio de dados; 3. Modelo dinmico, constitudo pelos diagramas de estado e diagramas de fluxo de eventos; 4. Modelo funcional, constitudo pelos diagramas de fluxo de dados e os constrangimentos associados A fase de desenho do sistema descreve a arquitetura bsica do sistema, bem como decises estratgicas de alto nvel, tratando-se de um refinamento da fase anterior, consistindo em: 1. Modelo de objetos detalhado; 2. Modelo dinmico detalhado; 3. Modelo funcional detalhado;
7.2.7 Processos.
Algumas atividades do mtodo podem ser feitas em paralelo, se for necessrio, e, depois da anlise, os subsistemas podem ser desenhados e implementados independentemente. Mas, existe uma grande distino entre anlise e desenho, o que no to notrio noutros mtodos OO. Os processos neste mtodo so descritos em quatro fases distintas, que so apresentados de seguida.
7.2.8 Anlise.
1. Escrever ou obter a definio do problema; 2. Construir o modelo de objetos, com as suas sete sub-atividades; 3. Desenvolver o modelo dinmico, com as suas cinco sub-atividades; 4. Construir o modelo funcional, com as suas cinco sub-atividades; 5. Verificar, iterar, e refinar os trs modelos, com as quatro sub-atividades;
7.2.9 Desenho do sistema.

1. Organizar o sistema em subsistemas; 2. Identificar a concorrncia inerente ao problema; 3. Alocar os subsistemas aos processadores e tarefas; 4. Encontrar uma estratgia bsica para implementar o armazenamento dos dados; 5. Determinar mecanismos para controlar o acesso aos recursos globais; 6. Escolher a natureza da implementao; 7. Manipular as condies de fronteira;
7.2.10 Desenho dos objetos.

1. Obter operaes do modelo funcional e dinmico; 2. Desenhar os algoritmos que implementam as operaes; 3. Otimizar os caminhos de acesso aos dados; 4. Ajustar a estrutura das classes de forma a permitir a herana entre as mesmas;
5. Desenhar a implementao das associaes; 6. Determinar a representao exata dos atributos dos objetos; 7. Colocar as classes e associaes em mdulos;
7.3 Booch
O mtodo de Booch constitudo, basicamente, por trs fases: Anlise de requisitos, que permite o estabelecimento das operaes fundamentais do sistema; Anlise do domnio, que permite a construo da estrutura lgica referente ao domnio em questo; Desenho, que permite a construo da estrutura fsica do sistema, fazendo o mapeamento da estrutura lgica anteriormente construda, conduzindo, assim, construo de prottipos; O objetivo do mtodo de Booch providenciar uma notao e um processo de desenvolvimento, dando especial ateno ao aspecto da comunicao entre a fase de anlise e desenho de um sistema de software OO. O mtodo de Booch tem um carter amplo que, endereando os aspectos das ferramentas de anlise e desenho OO, inclui modelao dos objetos, modelao da anlise, desenho da aplicao, desenho da implementao e ciclo de vida dos processos. Booch prope diferentes vises para descrever os sistemas OO. O modelo lgico, isto , o domnio do problema, representado na estrutura de classes e objetos. O diagrama de objetos mostra como os objetos interagem uns com os outros, enquanto que os diagramas de classe so de ndole mais esttica. Assim, os diagramas de objetos descrevem o comportamento dinmico do sistema. O conceito de subsistema, neste mtodo, entendido como um diagrama de mdulos, tendo um paralelismo, em termos do papel que representa, com os diagramas de categoria e de classes. Os subsistemas representam conjuntos de mdulos relacionados de uma forma lgica. Um sistema pode consistir em mltiplos programas, executando num conjunto de computadores distribudos. O diagrama de processos utilizado para visualizar a forma como os processos so alocados aos processadores, em termos de desenho fsico do sistema. Tipicamente, pode ser includo apenas um diagrama de processo. A arquitetura de mdulos e de processos lida com a alocao fsica das classes e objetos aos respectivos mdulos, processadores, dispositivos, e ligaes de comunicao entre eles, isto , descreve os requisitos de hardware concretos em relao aos componentes de software do sistema.
7.3.1 Conceitos
Este mtodo utiliza uma srie de diagramas para descrever as decises estratgicas tomadas nas fases de anlise e desenho, que devem ser consideradas quando criado uma sistema segundo o paradigma dos objetos.
7.3.2 Diagramas de classe

Um diagrama de classe consiste num conjunto de classes e relacionamentos entre elas. Segundo esta notao, existem vrios tipos de classes, cada uma representando um objetivo
especfico. As decises tomadas so capturadas nos diagramas de classe e nas suas especificaes. Os tipos de classes existentes so os seguintes: Class - Conjunto de objetos que partilham uma estrutura e um comportamento comum. Uma classe uma abstrao de um item do mundo real. Quando estes itens existem, so instncias da classe respectiva e so denominados objetos; Parameterized class - Neste tipo de classes so declarados, formalmente, parmetros genricos. Class utility - So classes no instanciveis, contendo um ou mais mtodos de classe; Metaclass - So classes cujas instncias so classes. Providenciam operaes para inicializao de variveis de classe, servindo como repositrios de suporte s variveis de classe, necessrios para todos os objetos da classe definida; Os relacionamentos so utilizados para indicar ligaes semnticas entre as classes. Cada relacionamento tem associado um label, indicando que tipo de relao que existe. O tipo de relacionamentos existentes so os seguintes: Association - Utilizado para indicar que existe um determinado tipo de relacionamento, mas a deciso sobre que tipo exato de relacionamento existe, pode ser deferida; Contains - Indica uma relao de estrutura entre duas classes. Pode ser utilizada cardinalidade. Os atributos e a agregao so casos particulares deste tipo de relacionamento; Inheritance - Indica que uma classe partilha a estrutura ou comportamento definido numa ou mais classes. Uses - Indica que uma classe cliente de outra classe, isto , utiliza os seus recursos; Instantiation - So relacionamentos entre uma parameterized class e uma classe instancivel; Metaclass - Mostra o relacionamento entre uma metaclass e as suas instncias, que so classes; Os tipos de visibilidade dos relacionamentos podem ser os seguintes: pblico, protegido e privado. A especificao de uma determinada classe utilizada para apreender toda a informao importante sobre essa classe, sobre uma forma textual. Esta especificao contm uma srie de campos que a definem. Para grandes sistemas, as classes podem ser agrupadas de uma forma lgica. Cada categoria pode conter um ou mais diagramas de classe. Os diagramas de categoria so utilizados para denotar a visibilidade entre as categorias das classes.
7.3.3 Diagramas de transio de estados

O comportamento dinmico associado com determinadas classes caracterizado utilizando este tipo de diagramas. So utilizadas, neste mtodo, as mquinas de estado hierrquicas de Harel's. Cada transio de estados liga dois estados. Um estado pode ter uma transio para ele prprio, e muitas transies podem partir do mesmo estado.
7.3.4 Diagramas de Interao de objetos.

Estes diagramas mostram a existncia dos objetos e dos relacionamentos, no modelo lgico do sistema. Existem dois tipos de diagramas de objetos. Um diagrama de cenrios, que
mostra como que um conjunto de objetos colaboram, de forma a implementar um mecanismo, mostrando o conjunto de operaes que devem ocorrer, como resposta a um determinado cenrio. Os diagramas de instncia mostram a existncia dos objetos, bem como os relacionamentos de estrutura existentes entre eles. Os diagramas de Interao mostram a execuo de cenrios da mesma forma que os diagramas de objetos. Assim, outra representao dos diagramas de objetos. Mas, desta forma, segundo Booch, mais fcil visualizar a invocao das mensagens na sua ordem. Os objetos so especificados no cimo das colunas horizontais do diagrama. As mensagens so mostradas com setas horizontais do cliente para o objeto servidor. A caixa vertical representa o tempo relativo que o fluxo de controle demora em cada objeto. Estes diagramas focam mais em eventos que em operaes, resultando, assim, um melhor resultado na captao da semntica dos respectivos cenrios.
7.3.5 Enquadramento Conceitual .

Um dos grandes pressupostos do mtodo de Booch criar um modelo do sistema, passvel de ser implementado. Os vrios conceitos deste mtodo esto distribudos, com diferentes nveis de abstrao, nas trs fases do processo, indicados a seguir.
7.3.5.1 Anlise de requisitos.

Neste mtodo, a anlise de requisitos produz dois tipos de especificaes formais. A primeira uma declarao das funes principais do sistema. Devem ser definidos inputs e outputs do sistema, ou uma lista de referncias para planos de ao, procedimentos, etc. A segunda a especificao de um conjunto de mecanismos chave que o sistema deve providenciar, incluindo o estado de entrada, sada e as mudanas de estado esperadas. Estes mecanismos chave servem para validar o domnio do modelo, descobrir operaes, bem como testar determinados casos.
7.3.5.2 Anlise do domnio.

Esta fase inclui: Diagramas de classe abstratos, que identificam as classes chave do domnio em questo, bem como os relacionamentos entre elas; Especificaes das classes, que contm todas as definies de ndole semntico das respectivas classes, os seus relacionamentos, atributos e operaes principais; Herana, que so diagramas de classe que revelam os nveis de especializao entre as classes; Diagramas de cenrios dos objetos, que ilustram como que os objetos interagem de forma a conduzir os mecanismos delineados na anlise de requisitos; Especificao dos objetos, faz o mapeamento dos objetos nas respectivas classes; Trata-se, portanto, de vises diferentes do modelo subjacente que contm a definio das classes, objetos, relacionamentos, etc.
30
7.3.5.3 Desenho.
Nesta fase, feito o refinamento do modelo criado na fase de anlise, adicionando as estruturas e comportamentos necessrios para implementao do domnio em estudo. O modelo iniciado durante a anlise serve como base para a construo do modelo de desenho. Nesta fase, so adicionados as seguintes contribuies ao modelo: Descries arquiteturais - So capturadas as maiores decises desta fase, tal como, escolha de processadores, gestores de bases de dados, sistemas operativos, linguagens, etc.; Descries do prottipo - Define os objetivos e contedo das implementaes sucessivas do prottipo, dirigindo o processo de desenvolvimento, testando o desenho e os requisitos; Diagramas de categoria - Modela as parties do sistema em grupos de classes e objetos, a um nvel elevado; Diagramas de classe - Descreve as abstraes da implementao a um nvel fsico, tipos de dados detalhados, ou estruturas, fazendo o mapeamento das abstraes do nvel lgico; Diagramas de objeto - Mostra a lgica operacional detalhada, de forma a cumprir as funes, incluindo a utilizao dos objetos fsicos; Novas especificaes - So feitas, suportando estes diagramas; Aperfeioamentos s especificaes das classes - Descreve as especificaes operacionais, de uma forma integral, para as operaes com algoritmos complexos, implementao de relacionamentos e tipos de atributos;
7.3.6 Processos e tcnicas.

Os utilizadores deste mtodo desenvolvem modelos de um determinado sistema, implementando-os diretamente em unidades de cdigo, denominados prottipos. O modelo construdo em estgios que permitem a concentrao em determinados aspectos do sistema, um determinado momento. Podem ser escolhidos diferentes diagramas para focar reas crticas do sistema. O resultado uma srie de vises claras e expressivas, como resposta a questes especficas sobre o desenho do sistema ou anlise de requisitos. Este mtodo tem como base o desenvolvimento de um sistema como um processo iterativo, isto , conceitualizaes anteriores devem ser complementadas ou refinadas, servindo o resultado como input do prximo estgio, de uma forma incremental. Assim, as primitivas codificaes da fase de desenho podem servir como forma de descoberta dos requisitos do sistema.
7.3.7 Anlise de requisitos.

A anlise de requisitos o processo de determinao daquilo que o cliente quer que o sistema faa. uma fase de alto nvel que identifica as funes chave que o sistema deve desempenhar, definindo o alcance do domnio que o sistema deve suportar, documentando os processos e planos de ao da organizao suportados pelo sistema. Os passos desta fase no so definidos formalmente, pois este processo varia de uma forma dramtica, j que depende de uma srie de fatores.
7.3.8 Anlise do domnio.

Nesta fase, definido, de uma forma precisa e concisa, o modelo da organizao, relevante para o sistema. neste processo que, ganho um detalhe de conhecimento do domnio necessrio para que o sistema cumpra as funes exigidas. Durante esta fase, so executados os seguintes passos: Definio das classes, que inclui a identificao dos objetos, bem como a sua definio; Definio de relaes, que inclui a descrio das associaes entre os objetos; Procura de atributos, que inclui a determinao dos dados que descrevem as classes e determinam quais as classes que necessitam da informao para as descrever; Definio da herana, que inclui a procura de generalizaes e especializaes, dentro de cada tipo de domnio; Definio de operaes, que inclui a identificao das principais operaes necessrias para suportar a estrutura das classes e as funes do sistema; Validao e iterao, que inclui a reviso, teste e reparo do modelo; Este processo altamente iterativo, isto , podem ser encontrados relacionamentos de herana, quando so descobertos os atributos.
7.3.9 Desenho.
Nesta fase, so determinadas, de uma forma eficaz, eficiente e de baixo custo, implementaes fsicas que cumpram a funcionalidade pretendida, bem como o armazenamento dos dados definidos na anlise do domnio. feito o mapeamento da anlise lgica, feita durante a fase de anlise de domnio, para uma estrutura que permita que os objetos e as classes sejam passveis de codificao e execuo. feito um refinamento contnuo e estendido ao modelo conseguido durante a fase de anlise de domnio atravs de: Determinao da arquitetura inicial, que inclui a tomada de decises a um nvel elevado de implementao de recursos e servios, as categorias de classes a utilizar e o prottipo a ser desenvolvido; Determinao do desenho lgico, que inclui a especificao de todos os tipos de dados e estruturas, operaes detalhadas, e decises de acesso aos objetos; Mapeamento para a implementao fsica, que inclui o desenvolvimento do interface e o mapeamento de input/output para esses servios atravs de classes intermedirias; Refinamento do desenho, que inclui o refinamento do prottipo e modificao do desenho para conseguir alguns requisitos de desempenho; Tal como a anlise, o desenho tambm um processo iterativo e incremental. Pode ser necessrio voltar anlise, quando so encontradas ambigidades e omisses. A iterao tambm feita pelos passos desta fase, medida que os prottipos vo sendo construdos, novas partes do sistema so integradas e prottipos existentes vo sendo estendidos, de forma a construir o sistema completo.
7.4 Jacobson
Este mtodo adequado para o desenvolvimento de software numa escala industrial. uma aproximao anlise e desenho orientado aos objetos, centrando-se na compreenso da forma como o sistema est e ser utilizado antes de ser feita a alterao pretendida. Organizando a anlise e o desenho atravs de seqncias de interaes com o utilizador e
utilizando cenrios, o mtodo produz sistemas bastante robustos e amigveis, adaptando as alteraes de uma forma suave. O mtodo divide o desenvolvimento em processos, que, diferentemente das fases de desenvolvimento tradicionais, podem ser iterados e sobrepostos. Estes processos produzem uma srie de modelos interligados, facilitando posteriormente a juno dos mesmo atravs de uma modelao consistente. Todos os sistemas se alteram durante o seu ciclo de vida, tendo a manuteno dos mesmos um peso muito grande em termos de custos de desenvolvimento. Muitos mtodos de desenvolvimento adequam-se a novos desenvolvimentos, mas tratando as revises do modelo de uma forma pouco adequada. Os desenvolvimentos iniciais devem ser vistos como uma atividade importante, estabelecendo uma arquitetura e uma filosofia que constitui a base do sistema. O mtodo descrito como um conjunto de processos que interagem entre si durante o desenvolvimento do projeto, atravs de diferentes modelos. Os processos principais so a anlise, construo e teste. No processo de anlise criado um modelo Conceitual do sistema a construir. Nesta fase, os modelos so desenvolvidos de forma a facilitar a compreenso do sistema, privilegiando a comunicao com o cliente. No processo de construo, desenvolvido o sistema a partir dos modelos criados anteriormente. A construo inclui o desenho e a implementao, resultando um sistema completo. O processo de teste integra os componentes do sistema, testando-o e decidindo se est pronto a ser distribudo ao cliente. O conhecimento do sistema aumenta sucessivamente maneira que o trabalho vai progredindo. Quando se est trabalhando na primeira verso de desenvolvimento do sistema, surgem novos requisitos e outros so alterados. Deste modo o sistema no pode ser completamente desenvolvido, at que as especificaes dos requisitos se mantenham constantes. Uma forma de resolver este problema atravs de desenvolvimento incremental. Na prtica, o sistema dividido em partes, correspondentes aos servios requeridos pelo cliente. Cada novo estgio de desenvolvimento estende o sistema com nova funcionalidade at que o produto esteja terminado. De tal modo que, esta estratgia incremental providencia um grande feedback durante o processo de desenvolvimento, resultando na execuo dos processos vrias vezes durante a mesma verso do sistema. Nesta aproximao, o modelo de use cases o modelo principal no qual todos os outros modelos so derivados. Um modelo de use cases descreve a funcionalidade completa do sistema, identificando como que o sistema externo interage com o sistema. O modelo de use cases a base das fases de anlise, construo e teste. O objetivo da anlise compreender o sistema de acordo com os seus requisitos funcionais. Os objetos so encontrados, organizados e as suas interaes so descritas. As operaes dos objetos e a viso interna descrita durante a fase de anlise. importante que os objetos sejam encontrados na fase de anlise. Na fase de teste, o sistema verificado, significando que a correo do sistema verificada de acordo com a sua especificao.
7.4.1 Conceitos.
O primeiro modelo desenvolvido a especificao dos requisitos. Consiste num modelo orientado ao caso em estudo, com descries do interface com o utilizador, e um modelo dos objetos do domnio. Este modelo baseado nos conceitos de actors e use cases.
Deste modo, define-se o que existe fora do sistema e o que deve ser executado pelo sistema, respectivamente. Os actors podem ser pessoas ou mquinas. Cada um deles pode executar um nmero diferente de tarefas, bem como participar na operao do sistema. Executa uma seqncia de transaes em permanente dilogo com o sistema. A uma seqncia especfica denominado use case. Cada use case uma forma especfica de utilizar o sistema. O conjunto de use cases corresponde aos requisitos funcionais do sistema a construir. O modelo de requisitos facilita a discusso sobre os mesmos e as preferncias do sistema, de forma a assegurar a definio correta do mesmo. Para suportar o modelo de use cases apropriado o desenvolvimento de modelos de interface, tendo os prottipos um papel importante na sua simulao. Adicionalmente, para comunicar com os utilizadores potenciais e obter uma concordncia estvel das descries dos use cases, um modelo lgico dos objetos do domnio apropriado. O modelo de requisitos formula as especificaes dos requisitos funcionais baseadas nas necessidades dos utilizadores do sistema. Uma vez definido e aprovado o modelo de requisitos, o desenvolvimento do sistema passa para a construo do modelo. Este modelo define a estrutura lgica do sistema, independentemente do ambiente de implementao selecionado. Embora possa ser utilizado o modelo de objetos anteriormente definido na fase de anlise, como base para a implementao, no resulta numa estrutura robusta. O modelo de anlise representa uma estrutura bastante mais estvel e fcil de posterior manuteno. Este mtodo reconhece trs tipos diferentes de objetos, separando o controle e coordenao, da funcionalidade relacionada com o interface e das entidades que personificam os conceitos da rea de aplicao. Desta forma, os tipos de objetos utilizados so entity, interface e control. Cada tipo de objeto tem um objetivo diferente. Os objetos entity modelam a informao do sistema que deve ser utilizada por um determinado perodo de tempo. Todo o comportamento ligado a esse tipo de informao deve ser colocado neste tipo de objetos. Os objetos interface modelam o comportamento e informao que depende do atual interface do sistema. Os objetos control modelam a funcionalidade que no genrica, mas especfica a um ou mais use cases, tipicamente comportamento que consiste em operaes sobre diferentes objetos entity, executando algumas computaes e retornando o resultado para um objeto interface. A distribuio da funcionalidade desta forma ajuda ao isolamento das alteraes, facilitando a posterior manuteno. Este mtodo no obriga criao de um modelo rgido baseado nestes tipos de objetos. O resultado um modelo robusto de uma aplicao, isto , um sistema que , fundamentalmente, mais fcil de ser adaptado a extenses e alteraes, junto com conjuntos de componentes que so mais facilmente reutilizveis. Assim, futuras alteraes ao sistema, no afetam a estrutura lgica do mesmo. O modelo de desenho entendido como um refinamento e formalizao do modelo de anlise. O principal objetivo adaptar o modelo implementao. Podem-se encontrar neste modelo, os seguintes conceitos: Actor - Define um papel que um determinado utilizador pode representar na sua troca de informao com o sistema; Role - O papel definido pelas operaes dos objetos; User - Pessoa que atualmente utiliza o sistema. uma instncia da classe actor;
Use Case - Curso completo de eventos especificando as aes entre o utilizador e o sistema; Object - caracterizado pelas operaes e estado associado; Entity Object - Informao que guardada por um largo perodo de tempo, mesmo quando uma use case completada; Interface Object - Objeto que contm funcionalidade da use case que interage diretamente com o ambiente; Control Object - Objeto que modela a funcionalidade que no est em qualquer outro objeto; Central Interface Object - Objeto de interface que contm outros objetos de interface; Attribute - Contm informao e o seu tipo; Class - Grupo de objetos que tm similar comportamento e estruturas de informao; Stimulus - Um evento que enviado de um objeto para outro, iniciando uma determinada operao; Message - Estmulo intra-processo, isto , uma chamada normal dentro de um processo; Signal - Estmulo intra-processo, mas uma chamada dentro de dois processos; Operation - Atividade dentro de um bloco que pode levar a uma mudana de estado do objeto correspondente; Subsystem - Grupo definido de objetos, de forma a estruturar o sistema;
7.4.2 Processos. 7.4.2.1 Anlise de requisitos.

Os modelos desenvolvidos descrevem o que que o sistema faz. A base deste modelo so os requisitos do cliente ou utilizador final, expressos de uma determinada forma. a compreenso por parte do analista, daquilo que o cliente quer, que deve ser expressada, podendo servir como um contrato entre o analista e o cliente. Este modelo consiste, normalmente, no modelo de use case com as descries de interface e o modelo dos objetos do domnio em questo. O sistema descrito como um nmero de use cases que so executados pelos actors. Os actors constituem aquilo que externo ao sistema a ser desenvolvido, podendo os limites do sistema serem estabelecidos. Cada um deles executa uma ou mais tarefas. Uma vez definido aquilo que est fora do sistema, a funcionalidade interna pode ser definida atravs da especificao de use cases. Os actors so a principal ferramenta para encontrar use cases. Um use case uma forma especfica de utilizar alguma da funcionalidade total do sistema. De forma a encontrar use cases podem ser colocadas questes como: Quais so as principais tarefas de cada actor ? O actor tem de informar o sistema acerca de alteraes externas? Um dos princpios fundamentais do desenho de interface a manuteno de consistncia entre a viso Conceitual do utilizador do sistema e o comportamento atual do mesmo. Utilizando um modelo dos objetos do domnio como uma base Conceitual para definir as construes semnticas do sistema e interfaces, poder-se- chegar a uma consistncia entre o interface com o utilizador e a sua perspectiva lgica.
35
Como os use cases focam certas reas funcionais da aplicao, possvel fazer o seu desenvolvimento para diferentes reas, juntando-as mais tarde para completar o modelo de requisitos do sistema.
7.4.2.2 Anlise de robustez.

Uma vez desenvolvido o modelo de requisitos e aprovado pelo cliente, pode-se centrar os esforos no desenvolvimento propriamente dito e na estruturao do sistema. O modelo desenvolvido totalmente orientado para a aplicao e no para a tecnologia de implementao, como seja o sistema operativo, sistema de gesto da base de dados, distribuio dos processadores, ou configurao do hardware. assim gerado um modelo Conceitual de configurao do sistema, consistindo nas vrias categorias de objetos. O objetivo deste modelo encontrar a robustez necessria e a estrutura do sistema como uma base para a construo. Cada tipo de objeto tem o seu objetivo especial para a robustez, e juntos, oferecem a funcionalidade total especificada no modelo de requisitos. Toda a funcionalidade que est diretamente dependente do ambiente do sistema colocado nos objetos de interface, sendo atravs destes objetos que os actors comunicam com o sistema. A tarefa dos objetos de interface traduzir as aes dos actors em eventos do sistema. Para modelar a informao que o sistema deve manipular ao longo do tempo so utilizados os objetos entity. Quando o comportamento no pode ser colocado de uma forma natural nestes dois tipos de objetos, so colocados nos objetos do tipos control. Geralmente, so objetos relacionados com seqncias especficas a um ou mais use cases, de forma a isolar os outros dois tipos de objetos, sendo, assim, facilitada a manuteno do sistema. Uma outra forma de facilitar esta tarefa alocar um objeto do tipo control para cada actor. Os objetos identificados so agrupados em packages, servindo como input para a fase de desenho. Estes packages reduzem a complexidade e estrutura do sistema, de forma a facilitar posteriores desenvolvimentos e manuteno do prprio sistema. Um package, no nvel mais baixo, deve estar relacionado apenas com um actor. Adicionalmente, todos os objetos com relacionados funcionalmente devem ser colocados no mesmo package. Outro critrio para a diviso a reduo ou minimizao da comunicao entre os diferentes packages.
7.4.2.3 Desenho.
A processo de construo composto pelo desenho, implementao e teste. Isto no significa que tenha de se esperar que todas as partes estejam construdas antes de iniciar a certificao do sistema, pelo contrrio, tenta-se fazer o mais possvel em paralelo. O processo de construo deve ser ativado muito antes do processo de anlise ter sido completado. O modelo de desenho um refinamento e formalizao do modelo de anlise, onde as conseqncias do ambiente da implementao tm de ser tidas em conta. O modelo de anlise no suficientemente formal, e, em vez de estarmos permanentemente a alterar o cdigo fonte, procedesse ao refinamento dos objetos, s operaes que eles devem oferecer, s comunicaes exatas que devem ter entre eles, que estmulos que so enviados, etc. No entanto, se so descobertos pontos pouco claros em relao ao modelo de anlise ou dos requisitos, devem ser feitas as clarificaes necessrias, voltando ao processo de anlise.
O modelo de desenho define explicitamente os interfaces dos objetos, bem como as semnticas das operaes. Este modelo reflete decises relacionadas com as bases de dados, linguagens de programao, distribuio, etc.. composto por packages e design objects. Os design objects vo ser mais tarde implementados em cdigo fonte e, neste caso, esto abstrados da futura implementao. Depois de identificar a arquitetura do sistema, deve ser descrito como que os packages e os design objects comunicam. Para cada use case concreto deve ser desenhado um diagrama de Interao, descrevendo como que o use case realizado atravs da comunicao entre os packages, que recebem e enviam estmulos. Estes estmulos, incluindo os parmetros enviados, devem ser definidos. Os diagramas de transio de estado podem ser utilizados num nvel intermdio, antes de iniciar a implementao. Estes diagramas formam uma descrio simplificada, aumentando a compreenso dos design objects ou de uma package, sem estarem dependentes da linguagem de programao selecionada. Estes diagramas descrevem que estmulos podem ser recebidos e o que acontece quando o estmulo recebido.
7.4.2.4 Implementao.
A implementao dos packages em cdigo fonte pode iniciar-se quando o interface do package estabilizar. Em muitos casos, cada design object corresponde exatamente a uma classe, tornando fcil o mapeamento. Em alguns casos, algumas classes podem ser implementadas para um dado design object, para implementao dos atributos, utilizao de componentes ou separao de funcionalidade comum em classes abstratas. Por conseguinte, cada design object continuar a ter um mapeamento no cdigo, mas suportando vrias classes que foram adicionadas. Sempre que possvel, duas classes no devem oferecer funcionalidade semelhante, a no ser que estejam relacionadas por um mecanismo de herana. Por exemplo, se metade das operaes de uma classe acederem a metade das variveis de instncia e as outras operaes acederem s outras variveis, devem ser consideradas duas classes. Existem outras heursticas para um bom desenho das classes, incluindo o julgamento da reutilizao potencial das mesmas. evidente que demora muito tempo a desenhar boas classes, e nem sempre eficiente desenvolver todas as classes do sistema o mais genricas possvel. Note-se que mantida uma linha de ao desde a fase de anlise at ao cdigo fonte. Quando se l o cdigo fonte, pode-se descobrir diretamente o que que o originou no modelo de requisitos.
7.4.2.5 Teste.
Nesta fase, feita a verificao do sistema construdo em termos de correo. Uma aproximao disciplinada e bem organizada ao desenvolvimento de sistemas resulta da necessidade de aumentar a qualidade do sistema, diminuindo os custos da fase de teste. Na metodologia, as atividades de teste so executadas inteiramente durante o processo de desenvolvimento. As instncias de diferentes classes devem ser integradas continuamente ao longo do processo. O conceito de use case crucial para a integrao, com um use case em cada momento a ser integrado. Os planos de teste podem ser feitos muito cedo, juntos com a identificao e especificao dos use cases.
37
7.4.3 Tcnicas.
Uma das tcnicas utilizadas so os diagramas de Interao, denominados message sequence charts pelo CCITT. Descrevem de que maneira que cada use case funciona, atravs da Interao dos diversos objetos. Tambm representado o interface com tudo aquilo que est fora do diagrama, como sejam os actors externos, que podem corresponder a interfaces externos do sistema. A descrio das seqncias feita de uma forma textual, tendo estas construes a facilidade de migrao para a linguagem de programao a implementar. Alm desta tcnica, so utilizadas outras bastante divulgadas noutros mtodos de desenvolvimento orientados aos objetos. Introduo No processo de desenvolvimento do software orientado a objetos necessrio ter uma viso mais ampla do que a oferecida pelo modelo esttico do sistema, pois este no reflete a mudana dos objetos e seu comportamento atravs do tempo. Para visualizar melhor o comportamento de um sistema composto por diversas classes so necessrias ferramentas que permitam representar as mudanas que ocorrem nos objetos, como mudanas que surgem como resposta a estmulos. O conjunto dessas ferramentas compe o modelo dinmico.
8. UML (Unified Modeling Language)

A UML ou Linguagem de Modelagem Unificada foi criada com o intuito de aproveitar as caractersticas positivas de outras metodologias de desenvolvimento orientado a objetos de forma a criar uma linguagem de propsito geral para modelagem de sistemas. O modo de descrever os vrios aspectos de modelagem da UML atravs da notao definida por vrios tipos de diagramas. Um diagrama a representao grfica de uma coleo de elementos, que contm informaes sobre uma parcela do problema analisado
8.1 Conceitos Bsicos

A modelagem dinmica aborda primariamente os conceitos de estado de um objeto e a transio deste objeto para possveis novos estados. Dessa forma, os valores dos atributos de um objeto em um dado instante conhecido como estado do objeto. Em determinado tempo os objetos trocam mensagem e estmulos entre si, desencadeando uma srie de mudana de estados. Um estmulo individual de um objeto a outro chamado de evento. A reao de um objeto a um evento pode resultar em uma modificao de seus atributos, bem como resultar em um envio de outro evento ao emissor ou ainda a um terceiro objeto. O padro de eventos, estados e transio de estados para uma determinada classe pode ser representado atravs de um diagrama de estados. Um diagrama de estados uma rede de estados e eventos, assim como um diagrama de objetos uma rede de classes e seus relacionamentos. O modelo dinmico de um sistema orientado a objetos consiste em mltiplos diagramas de estados (um diagrama para cada classe, definida anteriormente no modelo esttico) com um importante comportamento dinmico que mostra o padro de atividades dentro de um sistema.
Dessa forma podem-se definir formalmente os elementos bsicos da modelagem dinmica: Mensagem: na programao orientada a objetos, mensagem um protocolo de comunicao entre objetos. Uma mensagem representada como uma linha entre o emissor e o receptor da mensagem. Os tipos de mensagem em UML so: Simples: mostra como o controle passado de um objeto para outro sem descrever nenhum detalhe a respeito da comunicao por estes no serem conhecidos ou serem irrelevantes no diagrama. Sncrona: a operao que envia a mensagem completada antes que o receptor finalize a execuo; o retorno pode ser mostrado como uma simples mensagem, ou o retorno pode estar implcito na execuo da mensagem. Assncrona: quando o emissor envia uma mensagem e continua o fluxo normal de execuo independente da resposta do receptor (utilizada para modelar concorrncia). Sncrona com resposta imediata: quando a resposta a uma mensagem quase imediata ao envio da mesma. Estado: a representao de um estgio no comportamento de um objeto. Ele tambm pode representar a condio de um objeto pelo qual se pode aplicar um conjunto definido de polticas, regulamentos e leis fsicas. Um objeto muda seu estado quando alguma coisa acontece, o qual chamado de evento. Isto ocorre devido ao seu comportamento externo e como ele interage com outros objetos, ou devido a mudanas no seu estado interno. Estado representado por um retngulo horizontal. Exemplos de estado so: Joo (objeto) est doente (estado); O computador (objeto) est ligado (estado). Eventos: um evento algo que ocorre instantaneamente. uma ocorrncia de significncia, tem uma localizao no tempo e no espao e pode ter parmetros. No contexto do diagrama de estados um evento uma ocorrncia que pode ativar uma transio de estados em um objeto. Os eventos para uma dada classe podem ser descritos em um Diagrama de eventos, sendo representados no diagrama de estados com uma seta com o nome do evento, ligando um estado ao outro. Segundo [ERI98], definem-se conexo causal como conexes bem definidas entre eventos e aes, e no causal quando uma conexo no est bem definida entre o evento e a ao. H quatro tipos de eventos na UML:
Uma condio tornando-se verdadeira; Recepo de um sinal explcito de outro objeto (mensagem); Recepo de uma chamada devido a uma operao de outro objeto ou dele prprio (mensagem); Passagem de um perodo determinado de tempo (representado como uma expresso de tempo no diagrama de estados). A UML no fornece um suporte explcito a eventos de erros, mas os mesmos podem ser modelados como eventos estereotipados, por exemplo: <<erro>> falta_espaco_disco
39
8.2 Diagramas da Modelagem Dinmica

Os aspectos relativos modelagem dinmica de um sistema orientado a objetos so descritos em UML atravs de quatro diagramas que definem aspectos comportamentais de um sistema de forma a tornar explcita a interao entre os objetos modelados. As interaes so os comportamentos que compreendem o conjunto de mensagens trocadas entre os objetos para realizar algum propsito. De um modo geral as interaes envolvem invocaes de operaes e qualquer operao de troca de mensagens. De acordo com a nfase que se d para as interaes, estaremos optando entre um dos tipos de diagramas. H diagramas cujo aspecto central focar como as mensagens so enviadas atravs do tempo (Diagramas de Seqncia).
8.3 Diagrama de Seqncia

Esse diagrama mostra cada objeto definido em uma linha vertical e os eventos entre os objetos definidos em uma seta horizontal que vai do objeto emissor at o objeto receptor do evento. Este diagrama explicita a seqncias de eventos ao longo do tempo de durao dos objetos, mostrando a execuo de todo ou de uma parte do sistema. Um diagrama que mostra os tipos de objetos envolvidos no cenrio de utilizao [AMB98], as mensagens que podem enviar uns aos outros e qualquer valor associado com as mensagens. Segundo [AMB98], um cenrio de utilizao descreve uma situao da vida real com o qual um sistema pode ou no estar capacitado a lidar, enquanto que o diagrama do cenrio de utilizao mostra os cenrios e atores da aplicao a ser desenvolvida. Em UML, o diagrama de seqncia representado da seguinte forma: os objetos participantes da interao so colocados no topo do diagrama em um eixo vertical imaginrio, geralmente com o objeto que inicia a interao mais esquerda. Os eventos so colocados ao longo de um eixo horizontal imaginrio, em ordem crescente de tempo do topo para baixo. Se um objeto no esta presente durante todo o espao de tempo indicado pelo diagrama, o mesmo deve ser representado por uma linha pontilhada, sendo que se o mesmo criado, passa a apresentar linha cheia. No diagrama abaixo, tem-se trs objetos, cada um apresentado como linhas verticais, que esto envolvidas na solicitao de saldo num caixa eletrnico. O primeiro objeto o cliente que envia uma mensagem, representada por uma seta slida, para o terminal eletrnico para a passagem do carto para leitura da tarja magntica. Aprovado o carto, o terminal eletrnico solicita a operao desejada. O cliente envia mensagem da solicitao de saldo, e em seguida recebe a mensagem de solicitao de senha enviada pelo terminal. O cliente informa a senha para o terminal que envia uma mensagem para o objeto banco, solicitando o envio da senha da conta em questo. O objeto banco envia a senha correta para o terminal que em seguida informa o tipo de operao solicitado anteriormente pelo cliente. O banco envia o saldo e finaliza a caixa de execuo do mtodo no objeto. O terminal imprime o saldo e retorna a tela inicial que ser apresentada ao usurio.
40
O primeiro passo ao desenhar um diagrama de evento identificar a classe em que o cenrio de utilizao inicia que quase sempre ser algum tipo de classe de interface. Aps isto, percorre-se a lgica do processo de cenrio identificando cada mensagem que precisa ser enviada e para quem. Sempre que identificar um novo objeto adicionado uma nova linha vertical. Sempre que um mtodo for executado em um objeto adiciona-se uma caixa de invocao de mtodo. No topo da caixa existir uma mensagem vinda de outro objeto, que iniciou o mtodo. A partir da caixa podem existir mensagens enviadas a outros objetos que invocaro mtodos dentro destes objetos. Finalmente o mtodo ir finalizar e pode retornar um valor ao objeto que enviou a mensagem original que invocou o mtodo. Se um objeto enviar uma mensagem a si prprio deve-se demonstr-la. Segundo [AMB98], as trs principais razes para desenhar diagramas de seqncia que uma excelente forma de documentar o projeto. Deteces de gargalos, observando quais mensagens so enviadas para um projeto e por quanto tempo os mtodos invocados so executados pode-se obter uma compreenso de onde deve ser modificado o projeto para balancear a carga dentro do sistema. Outra vantagem, que diagramas de evento geralmente
fornecem uma idia de quais classes da aplicao sero complexas, o que indica que se deve desenhar diagramas de estado para estas classes.
8.4 Diagrama de Estados

Um diagrama de estado relaciona os eventos e os estados. Quando um evento recebido, a modificao de estado de um objeto depende do estado atual do objeto assim como do evento recebido. Uma mudana de estado causada por um evento chamado transio. Um diagrama de estado um autmato de estados finitos indicado graficamente como um grafo dirigido cujos ns so estados e cujos arcos so transies marcadas com os nomes dos eventos. Todas as transies que partem de um estado devem corresponder a diferentes eventos. Um diagrama de estados especifica a seqncia de estados causada por uma seqncia de eventos. Uma seqncia de eventos corresponde a um caminho atravs do grafo (ou do autmato). Um diagrama de estados descreve o comportamento de uma classe de objetos. Por este motivo todas as instncias de uma mesma classe tm o mesmo comportamento. Todas elas compartilham o mesmo diagrama de estados. Como cada objeto tem seu prprio atributo, assim tambm cada objeto tem seu prprio estado que resultado de uma nica seqncia de evento recebida. Objetos so independentes entre si. Os diagramas de estado podem representar ciclo de vidas finito ou infinito. No caso dos ciclos infinitos existem representaes em que no relevante conhecer de onde se iniciam os eventos por no se distinguir um estado inicial. A mudana em um diagrama para representar um ciclo de vida finito onde existe um estado inicial e um ou mais estados finais. Ao entrar em um estado inicial se cria um objeto, de forma semelhante chegar a um estado final implica a destruio do objeto. Isto acontece quando no se pode passar de um estado final a outro estado mediante um evento. Exemplo: quando se apaga uma vela esta pode voltar a acender. No estado final da vela ela estar sempre apagada. No caso especfico da vela acabar ao chegar o estado de apagada ser certo que tenha se destrudo (como objeto), pois no h maneira de voltar a acender. Em UML, os diagramas de estados possuem um estado inicial e vrios ou nenhum ponto final. Um ponto de incio (estado inicial) o estado em que objeto encontra-se assim que criado. Todos os objetos possuem um estado inicial e este representado como um crculo todo preenchido. O ponto de finalizao (estado final) um estado do qual no existe sada atravs de transio alguma e representado como um crculo em volta de um outro crculo menor preenchido. Um estado mostrado como um retngulo com cantos arredondados, que pode conter trs tipos de compartimentos: o primeiro define o nome do estado, o segundo opcional e mostra o estado das variveis e o terceiro compartimento, tambm opcional, mostra as atividades onde os eventos e as aes podem ser listados. Entre os estados esto as transies, mostrados como uma linha com uma seta no final de um dos estados. A transio pode ser nomeada com o seu evento causador. Quando o evento acontece, a transio de um estado para outro executada ou disparada. Uma transio de estado normalmente possui um evento ligado a ela. Se um evento anexado a uma transio, esta ser executada quando o evento ocorrer. Se uma transio no possuir um evento ligado a ela, a mesma ocorrer quando a ao interna do cdigo do estado for executada (se existir aes internas como entrar, sair, fazer ou outras aes definidas pelo desenvolvedor). Ento quando todas as aes forem executadas pelo estado, a transio ser disparada e sero iniciadas as atividades do prximo estado no diagrama de estados.
As transies so representadas pela chamada de um mtodo, embora nem todos os mtodos sejam representados como transies. As transies refletem tambm as regras de negcio. Um diagrama de estados deve ser desenhado para uma classe que tem os estados identificados claramente e sempre que esta exibir um comportamento complexo, por exemplo em ambientes de tempo real. Ao desenhar, primeiramente deve-se identificar o estado de criao e verificar se existe ou no um estado final. Ento definir quais os estados ou estgios que um objeto passa durante seu ciclo de vida. Definidos os estados, procurar por transies, verificando como um objeto pode sair do mesmo, se possvel. Diagramas de estado podem enviar mensagens entre-si, que podem ser representadas por flechas tracejadas com origem no objeto que est enviando a mensagem. O objeto destino deve ter uma transio correspondente para apanhar a mensagem. Para diagramas complexos, tem-se ainda a definio de subestado e superestado. Subestado um estado especfico que parte de um superestado mais generalizado. Quando um subestado pode assumir somente um estado num determinado momento definido como or-substate [ERI98], por exemplo, o carro pode estar no estado movimento e este pode ter dois subestados: avanando ou retornando. Quando um estado possui subestados concorrentes, definido como and-substate[ERI98], por exemplo, o carro pode ter os estados avanando e alta velocidade, avanando e baixa velocidade. Superestados so uma coleo de um ou mais subestados especficos, quando existem vrios estados relacionados que formam seu prprio subsistema.
43
8.5 Diagrama de Atividade

Diagramas de atividade capturam aes e seus resultados. Eles focam o trabalho executado na implementao de uma operao (mtodo), e suas atividades numa instncia de um objeto. O diagrama de atividade uma variao do diagrama de estado e possui um propsito um pouco diferente do diagrama de estado, que o de capturar aes (trabalho e atividades que sero executados) e seus resultados em termos das mudanas de estados dos objetos. Os estados no diagrama de atividade mudam para um prximo estgio quando uma ao executada (sem ser necessrio especificar nenhum evento como no diagrama de estado). Outra diferena entre o diagrama de atividade e o de estado que podem ser colocadas como "swimlanes". Uma swimlane agrupa atividades, com respeito a quem responsvel e onde estas atividades residem na organizao, e representada por retngulos que englobam todos os objetos que esto ligados a ela (swimlane). Um diagrama de atividade uma maneira alternativa de se mostrar interaes, com a possibilidade de expressar como as aes so executadas, o que elas fazem (mudanas dos estados dos objetos), quando elas so executadas (seqncia das aes), e onde elas acontecem (swimlanes). Um diagrama de atividade pode ser usado com diferentes propsitos inclusive: Para capturar os trabalhos que sero executados quando uma operao disparada (aes). Este o uso mais comum para o diagrama de atividade. Para capturar o trabalho interno em um objeto. Para mostrar como um grupo de aes relacionadas podem ser executadas, e como elas vo afetar os objetos em torno delas. Para mostrar como uma instncia pode ser executada em termos de aes e objetos. Para mostrar como um negcio funciona em termos de trabalhadores (atores), fluxos de trabalho, organizao, e objetos (fatores fsicos e intelectuais usados no negcio). O diagrama de atividade mostra o fluxo seqencial das atividades, normalmente utilizado para demonstrar as atividades executadas por uma operao especfica do sistema. Consistem em estados de ao, que contm a especificao de uma atividade a ser desempenhada por uma operao do sistema. Decises e condies, como execuo paralela, tambm podem ser mostrados na diagrama de atividade e so representadas por uma linha negritada tanto na gerao de aes paralelas como tambm na unificao das aes paralelas. O diagrama tambm pode conter especificaes de mensagens enviadas e recebidas como partes de aes executadas. No diagrama de atividade, o ponto inicial representado por um pequeno crculo slido e o ponto final representado por um crculo maior com um crculo menor slido dentro. As aes so desenhadas como retngulos com cantos arredondados e com a respectiva descrio na parte interna. Neste diagrama, um evento s relacionado a uma transio do ponto inicial primeira ao. As transies entre aes so representadas por uma flecha, onde freqntemente nada especificado indicando que a transio ser disparada assim que todas as atividades nesta ao tenham sido executadas. Objetos tambm
podem ser representados neste diagrama como um retngulo como o nome do objeto/classe dentro sublinhado. A sua interao com as aes representado por flechas tracejadas. Sinais (classe Signal) tambm podem ser enviados ou recebidos neste diagrama e so representados por um pentgono cncavo (recebe) e por um pentgono convexo (envia) sendo ligados por uma flecha tracejada.
Figura 4 - Exemplo de Diagrama de Atividade: O Evento Inicial gera uma tomada de deciso, podendo gerar uma ao para o estado final ou uma ao desencadeando aes concorrentes que podem ser visualizadas no diagrama
8.6 Estudo de Caso

Para um melhor entendimento da Modelagem Dinmica em UML, partiremos de um estudo de caso bastante comum: a modelagem de um sistema gerenciador de transaes bancrias. Em UML, define-se o modelo Esttico (composto pelos diagramas de Classe) e em seguida efetua-se a modelagem dinmica valendo-se de diagramas de eventos, de estado, de colaborao e atividade. O diagrama de eventos leva em conta a interao entre as classes para a execuo de uma tarefa especfica e o diagrama de estados e feito para cada classe em particular mostrando todas as possibilidades de estado do objeto. Na modelagem proposta, efetuaremos o diagrama de estado da classe Gerenciador de Transaes Bancrias que em nosso modelo responsvel pelo recebimento de solicitaes bancrias e operao do Sistema Gerenciador de Banco de Dados .
45
Figura 3 Bancrias
Diagrama de Estados para Classe do Gerenciador de Transaes
O modelo mostra os estados bsicos do sistema, onde visualiza-se os eventos que causam transies entre os estados bem como atributos das operaes.
9. O papel do Modelo de Informao no desenvolvimento de Sistemas

A modelagem de informao pode ser til em muitas situaes em que exista algum processo sistemtico em andamento precisando ser esclarecido. Considere por exemplo, a formalizao de conhecimento especializado para uso mais amplo dentro de um companhia. Pode ser que a companhia uma fornecedora de sistemas telefnicos para escritrios tenha um excelente engenheiro de configurao, algum que desenvolveu profundos conhecimentos e perspiccia em calcular. Se num proposto conjunto de telefones, cartes, cabos e opes de software, estes elementos podem ser reunidos para formar um sistema operacional de telefonia coma s caractersticas desejadas. A modelagem de informao, neste caso, seria til para extrair do engenheiro seu modo particular de pensar na configurao por ele desenvolvida. Se houver qualquer postura sistemtica em sua abordagem conseguiremos captar as unidades conceituais do seu modelo mental e os relacionamentos em que ele se baseia para avaliar as alternativas da configurao. Uma situao similar aparece freqentemente tanto no mbito de processamento de dados comerciais como nas aplicaes industriais e fabris: ao longo do tempo foi-se desenvolvendo algum tipo de processo, que pode estar inteiramente baseado em papis ou pode envolver certo nmero de sistemas de computao. Em qualquer dos casos, o resultado
um s: dificilmente vai-se encontrar algum na organizao que entenda isso tudo. Ao contrrio, a tecnologia da companhia est distribuda entre alguns especialistas, cada um deles, com conhecimento, convenes e prticas particulares. Quando chega o momento de alterar o processo surgem as maiores dificuldades: voc no sabe dizer o que possvel modificar sem com isso desmontar toda a operao. A modelagem da informao particularmente proveitosa numa tal situao pois pode ser empregada para integrar as diversa opinies de todos os especialistas, desta forma revelando abertamente os dados sobre os quais o processo est fundamentado. Observe que os dois exemplos acima existia escondida a idia de um sistema; uma unidade que possa fornecer respostas previsveis e adequadas e determinados estmulos ou entradas. No havia necessariamente a implicao de que haveria de ser envolvido um computador ou de que devesse ser projetado um software.
9.1 Processo de desenvolvimento de Software

No existe um nico processo correto de desenvolvimento de software apropriado para todas as situaes. As boas escolhas de processos de desenvolvimento de software so influenciadas por vrios fatores que incluem: Familiaridade de projetista com a rea de aplicao Existncia de um software que poderia se incorporado dentro do sistema a ser desenvolvido Especializao do projetista: quanta experincia eles devem possuir e em que rea? Responsabilidade para a construo do software: sua companhia precisa de um sistema de computador para resolver um problema particular. Sua companhia o adquirir j pronto, ter algum que o construa sob encomenda, ou ser construdo internamente? Juntamente com a advertncia (No h somente um caminho certo) apresentamos aqui o esboo de um processo de desenvolvimento de software que julgamos eficiente e adaptvel a uma gama razovel de situaes. Este processo subdividido em quatro fases: 1. 2. 3. 4. Anlise do problema Especificao externa Projeto do Sistema Implementao e Integrao
9.2 Fase de Anlise: Uma abordagem Orientada a Objeto

9.2.1 Objeto e Modelo de Informao
A primeira coisa a se fazer construir o modelo de informao para definir as unidades conceituais com as quais voc trabalhar. Durante esta operao importante continuar focalizando o mundo real o problema no a soluo para aquele problema, soluo que ser fornecida com o sistema automatizado do computador. Presume-se que voc conhea aproximadamente o centro do domnio do problema e que a partir deste ponto iniciar a identificao dos objetos. Se no puder identificar o centro, inicie em qualquer lugar e apenas continue trabalhando. Continue at Ter objetos que estejam ao menos uma camada margem do objetivo do sistema a ser construdo. Uma vez que voc
conhecer o objetivo formal do sistema ainda por um pouco de tempo, seja generoso: mais objetos levam somente a uma maio compreenso, o que no pode ser ruim.
9.2.2 Estados dos Objetos e Modelos do estado

Ciclo de Vida: Uma vez o modelo de informao tenha sido construdo, nota-se que os exemplos de alguns objetos podem ser considerados passveis de uma espcie de ciclo de vida. Por exemplo, considere um objeto Conta. Inicialmente, a conta pode ser julgada como inexistente. Ento aparece um cliente e faz um depsito, fazendo desta forma que ela passe a existir. Neste estado, o cliente pode efetuar ulteriores depsitos ou saques at o saldo da conta ser inferior a zero ou igual a zero. Agora a conta deve ser considerada como pertencente a um estado diferente: a descoberto. Agora podemos aceitar somente depsitos; saques no podem ser aceitos. Um depsito que deixe o saldo positivo provocar uma nova mudana de estado da conta. Eventualmente, o cliente pode querer fechar a conta fazendo-a alcanar ainda outro estado(fechada): em outras palavras, a conta chegou ao final de seu ciclo de vida deixando de existir. Diagrama de Transio de Estados. O conceito de vida pode ser formalizado com a ajuda de um modelo de estado. Este modelo pode ser mostrado numa representao grfica conhecida como diagrama de transio de estados. Neste diagrama, cada caixa retangular denota um estado. O estado representa um estgio no ciclo de vida para os exemplos do objeto interessado. Cada conta pode estar num estado diferente em cada determinado momento. O diagrama vlido para todas as instncias do objeto. Conta separadamente, porque, para a definio de qualquer objeto, todas as instncias devem Ter o mesmo comportamento. O comportamento no decorrer do tempo , em realidade, o que esta sendo formalizado pelo modelo e estado. Pode-se executar um diagrama de transio de estado da seguinte maneira: a partir de um determinado esta, ocorre um evento que causa uma transio para algum outro (possivelmente o mesmo) estado. Na entrada para o estado, as atividades associadas so executadas. A instncia est agora num novo estado, e nada acontece com ela at ocorrer outro evento Nota final: Para qualquer objeto que tenha um ciclo de vida, inclua um atributo estado no modelo de informao, por exemplo(estado, conta). O domnio deste atributo simplesmente uma lista dos estados que aparece, no modelo de estado correspondente. Coordenao dos Estados. Escolhendo de novo o exemplo Conta, consideremos o objeto cliente. Conta e Cliente devem ser coordenados de alguma maneira: Podemos supor que o modelo de informao expresse ao menos parte disso por meio de um relacionamento Cliente possui Contas (1:M). A mesma coordenao pode ser mostrada a nvel do exemplo usando modelos de estado para os objetos Conta e Cliente. Isto feito atravs dos exemplos. Neste caso, o modelo de estado de conta gera eventos que efetuam o modelo de estado de cliente.
9.2.3 Atividades e Diagramas de Fluxo de Dados

Ao se inspecionar as atividade num modelo de estado, rapidamente perceb-se que, apesar de criticas, elas tm um natureza de processoou de transormaes de dados. O que pode ser feito para tornar evidente este aspecto do problema? Diagrama de fluxo de dados(De Marco, 1977) uma ferramenta grfica paa a modelagem de transformaes e manipulaes
de dados. Utilizamos os diagramas de fluxo de dados para expor os detalhes das atividades a partir do modelo de estaod. Exemplificando, veja figura que mostra algumas atividades associadas com o projeto conta. As figuras ilustras os trs componentes de um diagrama de fluxo de dados: Os fluxos de dados, representados por flechas rotulada; Os processos, representados por crculos; e Os depsitos, mostrados como um par de linhas paralelas. Os depsitos so derivados diretamente dos objetos do modelo de informao e rotulados correspondentemente. Pode-se pensar que os depsitos so tabelas que foram preenchidas com dados para representar as instncias existentes. Os fluxos de dados so unidades ativas de dados pacotes de dados contendo os atributos nominativos. Quando um fluxo de dados chega, sofre uma mudana por parte de um processo, o qual pode tambm retirar dos depsitos os dados necessrios para executar sua tarefa. A fim de especificar exatamente o que um processo deve fazer, providencia-se um descrio detalhada para cada processo. As descries do processo podem ser representadas por meio de uma variante de notaes e de linguagens, inclusive por: texto narrativos em linguagem natural, linguagem matemtica, um pseudocdigo baseado em linguagens de inquirio relacional e rvores de deciso. Tudo o que importa que a linguagem ou o formalismo escolhido sejam apropriados para o processo a ser descrito.
9.2.4 Integrando os Modelos de Anlise

Os modelos de anlise declaram as unidades conceituais do problema (os objetos), o ciclo de vida por que passam os exemplos de cada unidade conceitual e o processamento requerido para acompanhar cada unidade em seu ciclo de vida. Estes aspectos de estado e no diagrama de fluxo de dados respectivamente. Os modelos so integrados, e o modelo de informao fornece a base para os outros dois, com mostrado a seguir: Os diagramas de transio de estados so construdos para os objetos que evidenciam um ciclo de vida ou um ciclo operacional. As transio de estado fazem as atividades ocorrerem. Estas atividades so representadas como processos num diagrama de fluxo de dados. Cada objeto do modelo de informao torna-se um deposito no diagrama de fluxo de dados. Os processos aceitam e produzem somente os dados que so definidos no modelo de informao. Os processos podem criar eventos que aparecem no diagrama de transio de estados. So estes relacionamentos entre os modelos de informao de estado e de processamento que conduzem estrutura da Fase de Anlise apresentada na figura.
49
Profa. Maria Cristina Basili Duarte Fontes primrias

Fontes primrias
Construir modelo de informao
Construir modelo de estados
MODELO DE INFORMAO
MODELO DE ESTADOS
Construir modelo de processos
MODELO DE PROCESSO
9.3 Fase da especificao externa

9.3.1 O que uma especificao externa
Os documentos de anlise, tomando em seu conjunto, fornecem o modelo abstrato de um sistema: uma entidade baseada nos dados, que se comporta em um modo sistemtico, definido e previsvel frente s entradas ou aos estmulos. Todavia, os documentos de anlise no informa quais so os processos que sero executados pelos computadores e quais sero executados pela equipe. O objetivo da fase de especificao externa a tomada de deciso quanto ao que o computados deve fazer e o que no deve fazer. Consideremos um problema bancrio. A anlise mostra que existem coisas como cheque, e que um cheque pode ser apresentado no banco para ser descontado. Quando isto acontece, o banco deve verificar 1) se h bastante dinheiro na conta para cobrir o cheque 2) se a assinatura no cheque aquela do cliente sobre cuja conta o cheque foi emitido O que os documentos de anlise no dizem quem ir fazer cada elemento das operaes das acima. A tarefa da especificao externa estabelecer quais das vrias alternativas tem sido escolhidas. Por exemplo, no problema bancrio, a especificao externa determinar qual entre os seguintes esquemas alternativos foi selecionado. O caixa pode digitar o montante do cheque e o nmero da conta e esperar que o computador informa Saldo OK ou No OK O caixa pode digitar o nmero da conta e o computador fornecer o saldo atualizado da conta. O caixa ento confrontar o saldo com o montante do cheque e determinar Saldo OK ou No OK.
O caixa poder procurar a assinatura num carto de assinatura usando o nmero da conta como ndice. O caixa ento confrontar a assinatura do cheque com aquela do carto de assinatura. O caixa poder digitar o nmero da conta e o computador apresentar uma imagem do carto de assinaturas.
Decidir entre estas alternativas tarefa difcil pois evolve a identificao de possveis implementaes, a determinao do custo de cada possibilidade e a determinao de quanto dinheiro pode ser poupado em cada escolha. Muitas vezes existem dimenses adicionais que so importantes para as decises: o tempo para implementar, a confiana nas estimativas de tempo e de custos, a confiabilidade da soluo proposta, e assim por diante. Atualmente, no existe nenhuma maneira sistemtica bem desenvolvida de se avaliar alternativas envolvendo todas as vrias dimenses relevantes. Sendo assim a estratgia mais racional que conhecemos isolar o problema: Ter certeza de que no momento em que estiver tomando tais decises, estar tomando somente aquelas decises. por este motivo que adentramos a fase de especificao externa por meio da fase de anlise.
9.3.2 Expressar a especificao definindo o limite

Uma estratgia que pode ser utilizada para expressar a especificao externa consiste em focalizar o limite de automao a linha imaginria entre a parte do sitema abstrato que ser conservada e a parte que ser deixada de fora. Uma especificao externa fundamentada no conceito do limite fornece basicamente um descrio em caixa preta do sistema a ser construdo. Esta especificao externa pode ser apoiada sobre o conceito de eventos externos: aqueles eventos dos modelos de estado que atravessam o limite da automao. Os documentos de especificao podem ser moldados em vrias formas, incluindo a lista dos eventos externos e o documento narrativo dos requerimentos.
9.3.2.1 Lista de eventos externos

simplesmente um lista concisa dos eventos que ocorrem logo fora do limite da automao e que requerem uma atividade para tomar lugar dentro da parte automatizada do sistema. Esta forma extremamente econmica, mas improvvel que seja aceitvel se a especificao externa deve formar a base de um contrato para o desenvolvimento de software.
9.3.2.2 Documentos narrativos dos requerimentos

Um documento narrativo dos requerimentos (s vezes chamados requerimentos funcionais ou especificao funcional) utiliza a linguagem natural para expressar o que o sistema automatizado deve fazer. Tal documento pode ser produzido de uma maneira concisa e organizada, convertendo em texto um lista de eventos externos. Ultimamente est na moda ridicularizar as formas de especificao baseadas em texto narrativo. As deficincias geralmente atribudas forma narrativas so: Redundncia;
Falta de preciso: diferentes leitores interpretam distintamente as mesmas afirmaes; Imperfeio, (dificuldade na avaliao para a perfeio); Inabilidade para avaliar a consistncia interna; Inabilidade para revelar as implicaes dos requerimentos; e Tamanho e organizao: os documentos so geralmente muito longos para ser lidos e assimilados. Estas deficincias realmente graves no so atribuveis ao uso da linguagem natural. Ao contrrio, elas surgem do fato de que a maior parte dos documentos narrativos dos requerimentos no est baseada num viso sistemtica do problema. Geralmente pede-se estes documentos que suportem o peso da prpria anlise. Essa situao melhora substancialmente quando o documento dos requerimento for sustentado por modelos abstratos do sistema (anlise). O modelo de informao define o vocabulrio de maneira cuidadosamente sistemtica: os modelos de estado revelam com clareza as restries intrnsecas do problema assim com as implicaes que podem surgir em se tornar externo qualquer evento particular: os modelos de informao, de estado, e de fluxo de dados so objetivamente construdos a fim de reduzir ao mnimo a redundncia, e o modelo de informao constitui uma base extremamente poderosa para a avaliao da totalidade.
9.3.3 Determinando a especificao por meio da definio do que interno

Como alternativa, a especificao externa pode ser desenvolvida localizando as partes do modelo do sistema (anlise) abstrato que sero colocadas internamente aos computadores. Tal orientao parecida com as formaes tradicionais do problema de especificao do sistema, tais como: - Qual o escopo do sistema automatizado? - Que operao o sistema executar? Os documentos de especificao externa podem consequentemente ser construdos diretamente sobre os modelos de anlise: Pode se registrar as decises do que interno examinando os documentos de anlise e assinalando cada elemento (objeto, atributo, relacionamento, evento, transio, estado e processo) que dever ser colocado dentro do computador. Nesta orientao do que interno existem duas desvantagens. A menos grave a de que, em certo sentido, tal especificao fornece dados em excesso. Enquanto todas as implicaes de uma deciso do que interno so claramente visveis, o detalhamento da especificao proporciona muitas oportunidades de distrao durante o processo de reviso. A desvantagem mais grave a de que tal especificao pode ser interpretada erroneamente e lida como afirmao do projeto do sistema. Isto absolutamente no convm. Uma especificao externa somente uma declarao do que o sistema far e no de como o sistema executara suas atribuies. A maioria das especificaes externas altera vrios projetos. Porm, parece que somente os projetistas e arquitetos de sistema mais experientes conseguem ver estas alternativa de projeto, e evitar desta forma a interpretao errada da especificao. A especificao externa, como foi desenvolvida at aqui, descreve somente o contedo da informao das transaes que cruzam o limite do sistema. O formato destas transaes deve se estabelecido a fim de proporcionar uma especificao completa de caixa preta do sistema automatizado. Isto realizado produzindo as descries de quantos dos seguintes formatos forem relevantes para a situao em pauta:
Diagramas auxiliares Formatos de relatrios Descries detalhadas de qualquer interface com outros sistemas automatizados Procedimentos do operador Tomando em conjunto, este requerimentos atestam como o sistema proceder a um usurio externo. Alm disso, muitas vezes necessrio, neste momento, declarar todos os requerimentos de desempenho, de confiabilidade, e assim por diante.
9.3.4 Integrando a Fase de Especificao Externa

Durante a fase de especificao externa, somente duas parte da informao esto sendo adicionadas. Primeiro, h uma declarao do limite do sistema e, segundo, h uma declarao de como o sistema aparece quela que interagem com ele. Estes novos dados so fortemente sustentados pelos modelos de anlise, e particularmente pelo modelo de informao. A informao que atravessa o limite definida em termos de atributos, e os requerimentos narrativos usam o vocabulrio que definido pelas descries do objeto e do relacionamento. A exposio da interface externa tambm declarada em termos de atributos. Os passos que compem a fase de especificao externa so mostrados na figura.
Modelo de Informao Modelo de Estados Modelo de Processos
Defina o limite do sistema
Declarao do limite (requerimento narrativo: lista de eventos externos Defina o limite do sistema
Interfaces Com outros computadores
Telas e relatrios
Procedimento s do operador
53
9.4 Fase de Projeto do Sistema

Neste ponto do ciclo de vida do desenvolvimento existe uma clara definio dos dados que devero ser conservados pelo sistema automatizado, e das operaes requeridas para agir sobre ele. Foi construda uma especificao completa do sistema, que agora deve ser passado aos projetistas do sistema. As questes fundamentais a ser tratadas nesta fase do desenvolvimento do software envolvem assuntos que devem ser decididos para o sistema como um todo, em vez de ser decididos para um s programa individual ou para uma s estrutura de dados. Estas so as decises csmicas que, se forem bem feitas, sobrevivero a todas as programaes. Elas incluem: Quais sero as regras gerais do sistema para a organizao dos dados compartilhados? Que regras gerais do sistema controlaro o acesso aos dados (para garantir sua consistncia)? Existe alguma regra que cada programa deve obedecer (tais como entrada/sada padro como em UNIX)? Quais so os dados que precisam estar dentro do sistema? Qual ser a base lgica para o particionamento do processamento requerido em programas? Que programas devero ser construdos?
Neste caso, em geral, muitas destas questes devem ser tratadas, pelo menos de forma parcial uma paralelamente outra. O que vem a seguir representa um s desdobramento do trabalho de projeto. Presumindo que estes passos sejam feitos em paralelo at a extenso requerida.
9.4.1 Projeto de Arquitetura de Software

Este passo declara as regras gerais do sistema para: A organizao e o acesso aos dados compartilhados; Ativao dos programas ( como deve ser chamado um programa) ; e Todas as convenes requeridas nos prprios programas. Estas convenes tem a ver com as interfaces entre os programas e so derivadas da organizao dos dados, do acesso aos dados das regras de acionamento do programa.
Pode no ser exigido quase nenhum trabalho na arquitetura do software. Por exemplo, voc poderia determinar que um certo tipo comercialmente disponvel de sistema de base de dados dever ser utilizado para organizar e controlar o acesso aos dados separados, que todo programa possa ser solicitado por um usurio num terminal e a qualquer momento, e que as nicas convenes requeridas nos programas para coibir a interferncia sejam aquelas impostas pelo prprio software do banco de dados. Por outro lado, se voc teve um sistema de controle de processo de tempo real ou problema similar de programas mltiplos, pode tornar-se necessrio grande quantidade de trabalho a fim de calcular as regra arquiteturais do software com elas devero ser aplicadas. Outra fase lgica para a participao poderia ser o desenvolvimento de um processador principal do modelo de estado e a codificao do prprio modelos de estado em
dados. As rotinas das atividades deveriam ser construdas como um conjunto de sub-rotinas, solicitadas quando necessrio pelos eventos no momento em que so aceitos e decodificados. Esta estratgia conduzir a um cdigo relativamente menor e a muito mentores dores de cabea, uma vez que o cdigo obrigado a ser bem estruturado a fim de servir de interface com o processador do modelo de estado. Uma terceira base lgica, s vezes usada somente parte do sistema, consiste em agrupar computacionalmente as operaes parecidas. Isto leva a poucos programas, organizados temporariamente. Muitos sistemas de controle de processos so construdos sobre este princpio: um, os programas para qualquer que seja a base lgica esta deve ser expressa claramente. Uma vez que isto tenha sido feito, os programas a ser construdos devero ser arrolados juntos com seus dados de entrada e de sada e moldados como objetos e atributos
9.4.2 Sumrio da Fase de Projeto do Sistema

Enquanto nas fase anteriores o modelo de informao era valioso pelo conhecimento da aplicao por ele transmitido, na Fase de Projeto do Sistema ele desempenha papel diferente: aquele de transmitir a estrutura intrnseca da informao que o sistema deve processar. Este uso do modelo de informao mostrado na figura que resume a fase de projeto do sistema dentro do processo global de desenvolvimento do software.
9.5 Fase de Implementao

A faz de implementao tem objetivo de gerar os dados e os programas preparados e testados.
9.5.1 Coleta de dados

Este aspecto da implementao conduzido principalmente a partir do modelo reduzido da informao. O modelo reduzido da informao deveria ser investigado para ver se h qualquer quantidade aprecivel de dados estticos (dados que no so modificados durante a operao) que possam ser requeridos no sistema automatizado. Se assim for, pode ser aproveitoso assumir uma abordagem sistemtica para obteno e verificao daqueles dados. Os passo s para tal abordagem sistemtica incluem: 1. Identificao das fontes. Examinar as fontes potenciais dos dados, estabelecer algumas determinaes a propsito da contabilidade de fontes conflitantes e selecionar as fontes usadas. 2. Definir procedimento de entrada. Decidir como os dados devem ser preparados para a entrada. Poder ser necessrio prescrever procedimentos manuais compreensveis, especialmente quando os dados devem ser obtidas de fontes compostas por documentos. 3. Preparar as Estruturas de Dados. Codificar as estruturas dos dados previamente estabelecidos no computador. Os detalhes desta tarefa dependem do software que esta sendo usado para manipular os dados do sistema em geral: se for empregado um sistema de banco de dados comercialmente disponvel, este passo requer a preparao e o processamento do esquema utilizado.
4. Dar entrada dos dados. Preparar os dados, inseri-los dentro dos formatos prescritos pelos procedimentos de entrada e processados gerando as estruturas permanentes dos dados compartilhados. 5. Verificao. Dever ser verificada a exatido dos dados. Esta operao pode Ter a simplicidade de imprimir e examinar relatrios e possivelmente confrontar os relatrios com fontes alternativas dos dados.
9.5.2 Projeto do Programa

Neste passo, os programas so repartidos entre os especialistas da implementao projeto. Cada implementador precisa ser municiado com a descrio da interface programa (desenvolvida no passo particionando em programas), assim como o projeto estrutura dos dados desenvolvido anteriormente e as normas arquiteturais aplicveis. A primeira ferramenta aplicvel para projetar a estrutura interna o Diagrama Estrutura. do do de de
9.5.3 Cdigo e Teste

Este processo consiste na construo dos prprios programas de acordo com o projeto do programa. Cada mdulo dever ser codificado e testado em separado, para ento ser progressivamente integrado, cada mdulo com seus chamadores e subordinados, a fim de produzir o programa. Este passo dever ser interpretado literalmente de modo a significar que a codificao est completa somente quando o programa for testado tambm com um unidade.
9.5.4 Integrao e aceitao

A integrao consiste em colocar juntos vrios programas e dados com o propsito de produzir um sistema. O passo da integrao inicia com programas que j foram testados, cada um por si, e com dados que j foram verificados, como discutimos anteriormente. A integrao o passo que verifica se estas unidades separadas, cada uma to correta como pode ser construda, se ajuntaro de fato uma com a outra para construir o sistema requerido. Em outras palavras, a integrao o teste do projeto do sistema. O projetista do sistema experiente, portanto, prestar muita ateno ao que acontecer durante a integrao. Ele, ou ela, definiro um sistema que possa ser integrado pea por pea e que contenha pontos e caractersticas de teste no nvel arquitetural para permitir a monitorao apurada e a confirmao do comportamento do sistema geral enquanto a integrao progride. Observe que tanto a integrao como a aceitao exigem um bom planejamento muito antes de suas execues. Alm disso, ambas devem ser objeto de uma abrangente verificao de que nosso trabalho foi corretamente executado. Uma vez que cada passo no processo de desenvolvimento do software tem sido derivado cuidadosamente e sistematicamente dos passos anteriores, e que cada um deles tem sido intensivamente revisado, a integrao e a aceitao no podero ser um eufemismo de refazer.
56
9.5.5 O papel do modelo de informao na fase de implementao

A fase de implementao consiste na construo real do sistema e numa verificao final de que o sistema construdo, em verdade, executa a tarefa para a qual se destina. Com exceo do passo da coleta dos dados, o modelo de informao entra apenas indiretamente na fase final do processo de desenvolvimento do software, atravs dos materiais, produzindo em fases anteriores, que foram derivados em parte de modelo de informao.
57
Referncias Bibliogrficas
Shlaer, Sally; Melo, Stefhen J.; Anlise de Sistemas Orientado para Objeto Martin , James; Odell J.; Anlise e Projeto Orientados a Objeto Martins, James; Princpios de Analise e Projeto Baseados em Objetos - Campus Ambler, Scott W.; Anlise e Projeto Orientados a Objetos - Volume II Editora Infobook, Rio de Janeiro, 1998. Eriksson, Hans-Erik, Magnus Penker; UML Toolkit, John Wiley & Sons Inc. ,1998. Fowler, M.; UML Distilled Second Edition - A brief Guide to the Standard Object Modeling Language, Prentice-Hall International, New Jersey, 1997. Furlan, J. D.; Modelagem de Objetos Atravs da UML - The Unified Modeling Language, Makron Books, So Paulo, 1998. Rumbaugh, J.; Blaha, M.; Premerlani, W.; Eddy, F.; Lorensen, W.; Object-Oriented Modeling and Design, Prentice-Hall International, New Jersey, 1991. Zambrano, J.; Travieso, E.; Integrated BOCA Framework Architecture and Design Document, Data Access Technologies, 1999.
58

Análise Orientada A Objeto - Apostila

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Análise Orientada A Objeto - Apostila

Загружено:

Авторское право:

Доступные форматы

Anlise Orientada a Objeto um resumo consistente

Profa. Maria Cristina Basili Duarte

Anlise Orientada a Objeto Sumrio

Profa. Maria Cristina Basili Duarte

Anlise Orientada a Objeto 20 22 23 23 24 24 25 25 25 26 26 26 26 27 27 27 27 28 28 28 29 29 30 30 30 31 31 31 32 32 32 33 35 35 36 36 37 37 38 38 38 40 40 42 44 45

Profa. Maria Cristina Basili Duarte

Anlise Orientada a Objeto 47 47 48 48 49 50 50 51 51 51 52 53 54 54 55 55 55 56 56 56 57 58

FACNET FAST - Anhanguera

Profa. Maria Cristina Basili Duarte

Anlise Orientada a Objeto

Profa. Maria Cristina Basili Duarte

Anlise Orientada a Objeto

2. Anlise Orientada a Objetos

FACNET FAST - Anhanguera

Profa. Maria Cristina Basili Duarte

Anlise Orientada a Objeto

3.1.1 Identificao de Objetos

Profa. Maria Cristina Basili Duarte

Anlise Orientada a Objeto

Profa. Maria Cristina Basili Duarte

Anlise Orientada a Objeto

3.2.1 Identificadores ou atributos determinantes

3.2.2 Descrio dos atributos

3.2.4 Especificao de Atributos

Profa. Maria Cristina Basili Duarte

Anlise Orientada a Objeto

Profa. Maria Cristina Basili Duarte

Anlise Orientada a Objeto

3.6.1 Herana simples

Profa. Maria Cristina Basili Duarte

Data admisso: Salrio Bruto: Mtodos Calcula salrio lquido

3.6.2 Herana mltipla

Nmero: Validade: Salrio Contratual:

Calcula tempo de casa

Profa. Maria Cristina Basili Duarte

Anlise Orientada a Objeto

Calcula tempo de casa

Profa. Maria Cristina Basili Duarte

Anlise Orientada a Objeto

4. Use Cases (Casos de Uso)

4.2 Caso de uso

Profa. Maria Cristina Basili Duarte

Anlise Orientada a Objeto

cursos alternativos: variantes do curso bsico e erros.

FACNET FAST - Anhanguera

Profa. Maria Cristina Basili Duarte

Anlise Orientada a Objeto

6.2 Diagrama de Fluxo de Objetos. (DFO)

FACNET FAST - Anhanguera

Profa. Maria Cristina Basili Duarte

Anlise Orientada a Objeto

6.2.3 Realidade e Informao Sobre e Realidade

Objetos e Operaes Externas

Profa. Maria Cristina Basili Duarte

Anlise Orientada a Objeto

6.2.4 A Funo de Um Processo

6.2.5 DFD X DFO 6.2.5.1 Diagramas de Fluxo De Dados

FACNET FAST - Anhanguera

Profa. Maria Cristina Basili Duarte

Anlise Orientada a Objeto

6.2.5.2 Diagramas de Fluxo De Objetos

6.3 Diagrama de Eventos. (DE)