Esta apresentao e baseada no projecto ESSI 10702 (CET-IN). Aborda a ternflea da melhoria do processo no campo da engenharia de software de tempo real. O projecto baseia-Se na aplicao da linguagem SOL-92 suportada pela ferramenta SDT para produzir um produto de telecomunicaHes para a rede publica. 0 trabalho realizado focou Osaspectos de engenharia desde a especificao ate a implement&o. As reas de interesse potencial na experincia so: a aplicao do SDL-92 e a sua ferramenta de suporte; o uso de metodos para desenvolvimento com SDL-92. Embora a aplicaco seja especifica para a industria de telecomunica5es, as conclus6es gerais sobre o uso do SOL-92 devero ser aplicaveis a qualquer sistema Queseja essencialmente de tempo real e de interfaces de mensagens discretas. A experincia decorreu no CET (Centro de Estudos de Telecomunica5es), o sector de investigao e desenvolvimento da Portugal Telecom em Aveiro Quee o departamento responsavel pela in"estigao e desenvolvimento de produtoS e aplicaJes para a rede PT. 0 CET composto por cerca de 200 engenheiros, dos quais 60 esto envolvidos em desenvolvimento de software. Aproximadamente 10 desses engenheiro tm estado envolvidos directa ou indirectamente na experincia. O produto destina-Se a aplicao na rede da PT e a primeira versAo encontra-Seja instalada em experincia piloto desde Julho/1995. A experincia decorre num ambiente de presso real para cumprirtlento de prazos de entrega. Os resultados so portanto realistas e no idealistas. O trabalho Quenecessitava de ser realizado no abrangia a analise de requisitos ou uma quantidade apreciavel de especificaco de alto nivel, pois o produto obedece a normas internacionais e a requisitos nacionais hem definidos. A melhoria mais significativa o grau de eflccia da tecnica usada: desenho e implement&o do sistema na linguagem SDL suportada pela ferramenta SDT (SDL Design Tool) da Telelogic, uma companhia sueca do grupo Saab Combitech. Embora o SDL tenha sido seleccionado neste caso devido a sua utilizao em telecomunica6es, e urn&linguagem que pode ser aplicada a qualquer dominio de tempo real baseado em estimulo"'resposta. 0 SDL tern sido utilizado numa ampla variedade de aplica6es desde bancos a controle ambiental de gastos e aeronautica.
~ . _ Page 1 ____________________
O ,
INTRODUCTION OO SDL.' software process improvement ESSI
nomeadamente no CET. De facto, os desenvolvimentos de equipamentos, serviOs e aplicaHes de gesto e operal;:Ao so exemplos de actividades qua o CET desenvolve para a Rede de Telecomunica6es da Portugal Telecorn (PT) qua trn um& parCel& de software muito gr&nae e em expansgo" .Assim, a sistematizao e o melhoramento dos processos de desenvolvimento de software no CET assume particular relevancia. Neste contexto uma das iniciativas nests area consistiu em apresentar uma candidatura ao program& comunitario ESSI (European Software System [nitiative / Software Best Practice - European Commission DG III), a qual foi aprovada e den inicio ao projecto ESSI 10702 (a decorrer desde I/6/ 94 ate 30/ I I/95) . O projecto consiste na aplicao de uma metodologia suportada por uma ferramenta CASE (SOT), que permite a Analise, documentac;;o especificaco, geral;:o autorntic& de c6digo, validao e teste. A ferramenta SDT3.0 implement& a lingua&em grafica formal SOL92, qua e uma linguagem nocmalizada pelo ITU-T, para uso nas TelecomunicaJes, mas tambem com uso crescente noutras actividades, designadamente em qua[quer apiica98o com caracteristicas de tempo real e de interface por mens&gens discretas, O c6digo gerado e "C" o qua generaliza o uso em diversas plataformas, A aplicaAo pratic& seleccionada fol uma vertente do projecto CET-IN. O CET-IN e urna platafOrma de servit;:os de telecomunica6es, permitindo a eriso e execuo de serviOs baSe&dos no conceito das Redes [nteligentes, assumindo a norm&Lizao internacional relevante nest& area, Exemp105 desses serviL;;:Os,que em breve se encontraro disponiveis na PT, so o Telecom Class
consideraveis: Os executavets desenvotvidos para Os diversos componentes do sistema tm cerca de 4 MBytes no seu conjunto. Varias tecnicas s8o empregues usando tecnologias de ponta no desenvolvimento de software: Unix, metodologias de orienta(;:o a objectos - ferramentas CASE: SOT, Objectory (analise/design) -, C, C++ So&bench,
desenvoZvimento de software desde os requisitos, analise, especificaco, implement&o e teste ferramenta SOT. do processo de
com base na
. - .
Considerando na engenharia de sistemas trs fase principals - especificaco, desenho e implementaco - o papel do engenheiro e da lingua&em utilizada pelo engenheiro e diferente em cada fase. Durante a especificao, a preocupao primordial e a captura de ideias a partir dos requisitos e a sua modelizao como uma especificaco, para cue o dialogo sobre as ideias possa ter lugar. Na lase de desenho, s3o utilizadas linguagens para a formalizao, partico e estruturao dos conceitos, para que Se possa dividir o problema em partes mais facilmente implementaveis. As lingua&ens formais sAo muitas vezes utilizadas para a comunica(;go entre engenheiros de desenho, e a lingua&em utilizada para a especificaco e um factor importante.
A Chane paa o sucesso de um sistema e a completa especificao e desenho. Isto exige uma liguagem de especificaVo adequada, obdecendo a: conj'unto ac conceitos hem definidos,. especcac6es sem ambiguz"dade, claras, exactas e concisas,.
urna base para an6lise dos especcaq6es no que diz respeito a deterrninaco se esto compLetas e a sua exaccidao,.
uma base para determinar a conformidade das implementa5es face as especifica5es; uma base para determinar a consistncta entre si do conjunto das especificaBes; utilizao de ferramentas baseadas em computador para criao, manuteno, anaIlse e Simulao das especificaBes,
implementaHes mas deve abstrair-se numa primeira fase dos detalhes de implementaco para dar urna panormica geral de um sistema complexo adiar decis6es de implementaco, e ' no excluir implementaJes validas
que comuniquem por passagem de mensagens. No ser to apropriada, pelo menos directamente, a areas em que predominem interfaces de utilizador para comunicaco Hornem-maquina hem como para o desenho de objectos em que haja urna Brande envergadura de dados de informao (Bases de Dados) Os requisitos dos sistema de telecomunicaHes so particularmente exigentes pelo que se estes podem ser satisfeitos de um modo econ6mico, ento certamente que outros tipos de sistemas apresentaro poucos problemas a utilizao de SOL.
Page 3
System COr.fveerrtt I(,I1f f I,,!nf[sl = I~__I4; _ fQOIu.t.[fttIr|.n - - ~Ol.1.l1t - prOCess ? Estrutura - abarca a composio de blocos (block) e processos (process). O SDL e estruturado por forma a permitir a facil compreens5o de um sistema ou para reflectir a estrutura (pretendida ou realizada) de um sistema. Ha uma relac,o forte entre estrutura e interfaces. Os tipos (Type) (p.e.. blocos e processos) podem ser utilizados para estruturar a descrio do sistema e para descrever as partes Quepodem ser re-utilizadas no sistema ou em outros sistemas. E possivel a definiVo de tipos Que"herdem" propriedades de outros tipos.
Interfaces destina-Se a descrio de sinais (signal) e vias de comunicaco para sinais. A comunicao assincrona pelo Que quando um sinal e enviado de um processo podera haver um atraso antes de ele atingir o seu destino e o Sinai pode ficar em fiIa de espera mesmo depois de chegar ao destino. As vias de sinais esto relacionadas com a estrutura do sistema. O cornportamento do sistema e caracterisado pela comunicao apresentada nos interfaces exteriores. Os sinais podem comer dados e portanto a sua defirli50 e dependente dos tipos dos dados. Comportamento - tern a ver com o envio e recepo de sinais hem como com a interpret&o das transi6es nos processos. A interpret&o da comunicao de sinais entre processos e a base da semntica de urn& definio SDL A intrepretao depende dos interfaces, da estrutura e particularmente dos dados.
Dodos - so usados para armazenar inform&o. Os dados armazenados em sinais e processos so usados para decis6es no interior dos processos. Excepto para Os sistemas extremamente triviais a utilizao de tipos de dados e fundamental para eliminar texto informal das definiJes SDL. O SOL tern duas formas de represent&o: SDL/GR Represent&o Grafica e SDL/PR Representaco Textual. A maior parte dos utilizadores prefere a representso grafica baseada em ferramentas, pois e mais facil de ler e compreender. 0 CET usa SDL/GR. Nev ludo no SDLIGR grafico: alguns items, tat como nomes, no podem ser expressos graficamente pelo Que essa parte do SOL/GR textual. Esta pae comum text1 coble: deni5es de dados, express5es e atribuiBes. A linguagem na sua foa completa inclui de facto ambos SDL/PR e SDL/GR.
Page 4 --. reatc | sta ll c|e Os Mapas de Sequncias de Mensagens - Message Sequence Charts (MSC) - so utilizados para especificar sequncias de mens&gens exempLificativasda utilizao do sistema para ocorrncias normals ou excepcionais. Os MSCs so to fceis de compreender que podem ser considerados intuitivamente 6bvios. Os MSCs podem ser utilizados como base para discusso com Os utilizadores do sistema.
Frequentemente Os MSCs so utilizados como esboOs intermediarios do comportamento do sistema hem como das suas partes intemas. Isto ajuda o engenheiro a compreender o que o sistema deve de facto fazer.
Os MSCs Que tratam o sistema como urna instcia (isto e como uma "caixa preta') podem ser parte dos requisitos de um sistema podendo at ser utilizados em documentos contratuais. Quando Os MSCs so deste tipo, devem ser mantidos durante o ciclo de vida do projecto. Durante & elaborao de uma aplica8o e da diviso do sistema em blocos e processos.. Os MSCs so utilizados para determinar a comunica(;:5oentre as diversas partes do sistema, O exemplo dado consiste na libertao de uma chamada telef6nica. Estes diagramas fazem parte da descrio do sistema. Devem ser mantidos ao longo do ciclo de vida do projecto e aplicados na fase de teste da aplicao.
Adicionalmente aos MSCs criados durante o desenho de uma aplicao, havera necessidade da criao de MSCs complement&res por foma a cobrir situaHes no usuais hem como sequHncias Que nunca deveriam ocorrer. Estas nltimas so hem importantes para testar a robustez do sistema. Os MSCs podem expressar apenas alguns dos traOs de comportamento do sistema No podem ser uti\izados para especificar completamente o comportamento do sistema. Contudo viabilizam uma viso alternativa util e permitem comprovar o comportamento do sistema.
No projecto do VSSP, detalhado mais a frente , &!gunsproblemas potenciais no desenho foram descobertos atravs da utilizao sistematica de MSCs. 0 MSC do exemplo omite algum detalhe nas mens&gens.Muitas das mens&genstm parmetros Quesko usados pelos processos, como por exemplo a identificaBo da origem e destino da chamada telef6nica. Quando Os processo 550 definidos o comeudo das mensagens pode ser identificado e definido tambm. Para a realizao de testes o conteudo tern mesmo de ser definido efectivamente.
Page 5
. Telelogic SOT(SOLDesign Tool) . Crapnfc cl Editor for SOL-92 . MSC Ed1o:r
Documentation of MSC to ITU-T2, 120 ' A u tomotc Genera tion from SOLsim![lot ' Simulator ' Trac e b ehaviour on SOLdiagrams ' Trace behavlour in MSC ' Debugging support ' va]i"dator (state space explorOtion) ' Deaaloc!<, signal rcce, array b ounds ' Ch ecks SOLagainst (m Or`1ually defined) . C-Code Gen eration ' C++
on HP fa HP forge ' XOB (HP UNIXsymbolic debugger
a_ ,,,,
" ," A utilizao de uma linguagem como o SDL no pode ser separada da disponibilidade de suporte em ferramenta. A ferramenta de suporte SDT da Telelogic, permite a analise, especifleaco. documentao, gerao automatica de c6digo e ainda o teste do software. A verso SDT3.0 suportando a verso SDL-92 da linguagem encontra-se disponivel desde o primeiro trimestre de 1995, A anterior verso suportava o SDL"88. A ver.so actual contem: ' ' ' um editor grafico para SDL-92 dotado de um analisador para a sintae e semtica, Mecanismos de importao e exportso de SDL textual (SDL/PR) para que possa haver comunicao com outras ferramentas Que suportem SDL/PR. um editor grafico de MSCs com a possibilidade adicional de gerao durante a Simulao do SDL. automatics de MSCs Gerao de c6digo C com bibliotecas de Simulao. Durante a Simulao o comportamento do sistema pode ser rastreado directamente nos diagrams SDL e em MSCs gerados automaticamente durante a Simulao. um Validador para detecco automatica de falhas nas especifica6es SDL e Validao automatica de MSCs. O Validador verifica automaticamente o comportamento do sistema SDL no sen ambiente definido e detects erros dinicos de tempo real tal como "dead!ocks", "signal race", acesso deficiente a variaveis, etc. Para alem disso, verifies c6digo C que tenha sido incluido nas especifica6es SDL. Valida automaticamente que as operaJes do sisterns (manualmente defmidas atrav6s de Mses) esto de facto implementadas no sistema em teste.
GeraV;o de c6digo fonte C, para interfaces IlO, interfaces de hardware e sistema operative, "kernel" final e o monitor de Simulao interactiva, pelo Que e assim possivel gerar automaticamente apiicaBes completas e executaveis.
A verso anterior, SDT 2.3, apresentava um conjunto de facilidades excepto Que no suportava SDL-92. Devido a este motivo a experincia foi repartida em 2 fases: utilizako baseada em SOT 2.3, seguida de explorao das novas funcionalidades do SDL-92 e SDT 3.0.
Page 6 - ~ 1 2. 3, 5, 6. 78, 9.
understand by Inspection of source documents. ~
for target environment.
10. [)oCument for re-work and enhancement.
~,I." Em muitos casos a quantfdade de trabalho empregue na anafise formal podera ser trivial, pois existem no sector das tefecomunicacHes normas hem documentadas, peto que a maior parte dO traba!ho concentra-se na formafizaco. Os seguintes pressupostos so tidos em considerao na definiAo da metodotogia; f A maior parte das apficac6es do CET tero:
.\ metodofogia cons(Ste pOrtanto nas seguintes activ!dades.. f Compreender a apfi'cao
Peta "inspeco"
do material base (ver Olsen Chapter 6) 2. Esboar um diagrama de blocos (SOT, ou papef e fapis e quafquer ferramenta grafica, Ou atraves da utifizaco de um diagrama dos requisitos) descrevendo as entidades do sistema e ambiente envofvente da apficaco. Esta acVo permite a identfficao das fronteiras da apficaco hem como a fixaco de nornes e entidades do sistema.
apt !cao. fdent!ficar conjuntos de sequncias e o texto correspondence. entre Os objectos do meio envofvente e a f . Desenhar a estrutura de blocos dentro da spiteso usando a ferramenta SDT com canals e rotas de sinais~
Juntar casos excepcionais e casos de erro em parafeto ao desenho dos processos. 6. Desenhar 05 processos SDL. As etapas de formafiza(;o descritas em Olsen Capitufo 6 poder5o ser utifizadas comO gUfa"Na execuo de um prolecto e uSuaf um processo ser atribuido para efeitos de impfementao a urns pessoa. 7. Vatidar cada processo, depots os blocos e finafrnente o sistema. Usar a teenica de "walktbroughs" e inspecdo por outro efemento da equips do projecto no envofvido na impfementacdo de cada parte a inspeccionar. Cada processo compfetado e vafidado com base na utifizago das facifidades oferecidas pets ferramenta.
Page 7 \NTELL\GENTNETWOR K {IN) Principles . ArchitectUraj concept applicable to
telecommunication networks ' Rapid servlce creation and deployment
Capability to customise services ' Service implementation
independence * Network implementation
independence * Network nodes switching connections
commanded by centralised intelligent nodes 0 termo Rede Inteligente - Intelligent Network (IN) - utilizado para descrever um conceito arquitectural destinado a ser aplicvel em todas as redes de telecomunicaHes. O objectivo facilitar a introduo de novos servios de telecomunicaJes de forma rpida e flexivel, e poder modificar servios ja existentes dotando-Os facilmente de novas funcionalidades.
Os objectivos da IN so: permitir criao de serviOs rpida
e em moldes econ6micos ' independncia da implement&o dos servios/rede num ambiente multivendedor. A independncia da implement&o garante ao fomecedor de servio ser aut6nomo na disponibilizao de novos serviOs face aos vendedores tradicionais de equipamento de telecomunicaJes. Estes objectivos so conseguidos atrav6s da separao entre o controlo bsico da chamada e do controle dos serviOs. Os servios so construidos com base em blocos bsicos element&res que podem ser utilizados numa diversidade enorme de serviVOs.Tipicamente ambas as fun(;6es de controle de chamadas e controle de serviOs so implementadas em entidades fisicas diferentes, sendo o controle de servios centralizado e o controle de chamadas distribuido pela rede.
SCE
Service
Creation Environment SCP - ServiCe Control Point SS P IP
S erv j Ce Switching Poi nt Intelligent
Peripheral PSTN - Public Switch Telephone Netwo
Creotion/dep ]O ymejj I SMS/SCE ' ,`,1- "!,., .!,1- ! ',-~ ' Sta'ii 5ti C$ ' SerVice ' C Iienrs SCP . ,`:,",,,r->,!,
'- CSQervi-|:crl eB~ ~ti=O(enCUIIj On SSF::) !P ' ServjCO CCCe5S ' BOslC CO// COnirOl Ooleo Hon
TrgGer Pnts deteo Hon . peccl fu n Cr(OnS under SC? conr (VoCo rnesscges. user interccHon)
caracterizada pelo seguinte: as entidades funcionais e as entidades fisicas da arquitectura [N~ a qual e
chamadas do tipo IN. Nalguns casos o SCP contem tambem a funo de acesso a dados (Service Data
eemplo anncios e recolha de informac80 do utilizador via marcao telef6nica.
mbiente de Criao de Servios (Service Creation Environment): o SCE suporta a criao de serviOs.
$.\IF) e apresenta interaces com todos Os oucros eiementos da arquitectura . A funo SMF responsvel por erir o fornecimento de seiOs aos clientes e utillzadores, instala20 de novos SeiOs e controle geraJ dos componenes da rede. Posslbilita o acesso a todas as entidades ncionais para a transerncia de informao relacionada com a l6gica de seio e com cs dados de seio.
-Pae 9
'c7smncuuuuuccal SImecCmvmvvVciCEqcCoeC LLsJ!mwwVccic4tLEcmE4lc4u4muE.Xn.i; uPLoucimnctc lvv::S!)S~Pr cET-
S
Links PC_A
SPC_B everal Orgins .. _. . _._. _. Bi-directional nd Destinations CIC X-~.,
everal.
LJestlnatlons
IC-X-32,-.
Circuits (E&M) Tradicionalmente, o SSP como entidade de comutao, inclui a funo CCF pois esta funo necessita de aceder aos recursos de um comutador para a sua misso de providenciar comutaco entre circuitos de entrada e safda. No entanto, e possivel pensar numa arquitectura derivada em Que o CCF Se localize numa entidade flsica diferente da Que realmente executa a comutao de liga5es`. A unica condio Queo CCF terms conhecimento das ligaJes entre circuitos de entrada e sa{da,utilizando para isso o esquema base da figura.
A aplicao seleccionada para a experincia o desenvolvimento de um interface de suporte a um pacote de BerniOs de telecomunica6es (Carto Virtual de Chamadas, Numero Pessoal, Linha Pessoal). Estes BerniOs so do tipo dos definidos no conjunto de normas IN design&dopol ETSI CS-1 (Capability Set 1). Uma plataforma comercial de hardware/software (HP 9000/827) utilizada corno infraestrutura de suporte a implementao de um "Virtual Service Switching Point"`"(VSSP). O software na experincia implementa um interface a sinalizaco de rede entre comutadores (Message Transfer Part - MTP of ITU-T Signaling System No 7 ). Este interface complementado com o tratamento do controle de chamada e SSF, possui ento um interface ao SCF e ao S controlando um Periferico Inteligente (IP) ligado ao comutador.
Na tigura pode observar-Se uma panorica da arquitectura do VSSP. O VSSP e uma das partes constituintes do n6 de serviOs implementado na plataforma HP. As chamadas de entrada provenientes da rede pbiles invocando serviOs prestados pelo n6 de serviOs so encaminhadas via circuitos bidireccionais associados ao Ponto de Sinalizao atribufdo ao n6. A sinalizao utilizada para controlar as chamadas o !SUP do SS#7 sobre MTP. Os circuitos so ligados em "loop" ao comutador evitando-se a funo de comutao no n6 de setviOs, Que Se serve das funcionalides inerentes ao comutador da rede publics. Cada circuito com CIC (Circuit Identification Code) ntur1ero X sempre ligado ao circuito X132. Esta relao fixa entre Os 2 circuitos e utilizada pelo !SUP (ISDN.User Part, sinalizao entre comutadores digitals) no VSSP para "comutar" a chamada Quando uma chamada necessita de ser ligada ao destinatrio ou ao IP, a ligao e controlada pelo VSSP atraves do envio de mensagens [SUP para a rede pblica para o circuito Xl32 O m6dulo VSSP do n6 de serviOs, comunica com o SCF e com o S. e este controla o IP Quetarnbm esta ligado a rede pblica. O VSSP trata o reconhecimento de "Trigger Points" no processamento da sinaliza50 (ver recomendaBes ITU-T da srie Q.1200), comunica estes eventos ao SCF e aguarda instruJes provenientes do SCF. A comunicado com o SCF baseia-Se nas opera6es norrnalizadas {NAP (Q.1218) sobre TCAP.
Page 10 _ .---"0 esforo para a produo com base em SOT do VSSP 1.0 fol de cerca de 20 Homens-Ms. Esta verso funcionalmente equivalente a uma verso produzida anteriormente (baseada em C e
IX) cujo esforco foi de ceca de 80 HM. Os dois numeros no podem ser comparados simplisticamente pois: ' os engenheiros envolvidos foram os mesmos e conheciam hem a aplicao anterior hem como toda a problematica envolvente; ' o sistema anterior fol concebido para outra plataforma (RMX) ' era a primeira vez Queo SOL estava a ser utilizado; provave!mente 40 HM seriam suficientes para desenvolver de nono o sofr\vare da primeira verso utilizando o metodo anterior.
Embora utiliZanfdOo SOL/GR, utilizou-Se come termo de comparao o numero de linhas de SOL/PR tetual gerados a partir do SOL/GR grafico. O SOL/PR tern exactamente o mesmo significado do SOL/GR mas sendo o texto substituido por simbolos graficos, viabilizando uma leitura mais facilitada nos utilizadores. 0 SOL/PR gerado automaticamente como base para a analise e geraco de c6digo. Complementarmente ao c6digo gerado pela ferramenta ha mais cerca de 1 linhas de c6digo C para o ambiente envolvente. A concluso Que para a mesma t`unconalidade o c6digo objecto gerado e cerca de 3,4 vezes maior, mas foi escrito 2 vezes mais rapidamente. Os numeros acima indicados correspondem ao SOT 2.3 e ao VSSP I .0. Um errO de menor importncia fol descoberto durante a opera{;:o,e o numero de erros descobertos no processo de desenho propriamente dito foram significativamente em menor quantidade do Que na experincia prvia. O erro descoberto na operao era um valor incorrecto na descodificacBo de um parmetro de uma determinada mensagem. O paretro deveria tel sido ignorado. mas um valor incorrecto causava a gerao de uma mensagem inesperada em determinada lase da charnada o que era de imediato tratado abortando a chamada em curso. Algumas chamdas falhavam ento devido a isso. A ocorrncia desse valor no tinha sido testada previamentfe.
Na abordagem previa (C e RMX) o sistema tinha sofrido de uma qquantidade apreclavel de erros de desenho associados ainda ao envio de mensagens para o destino incorrecto. O uso de SOL e SDT ajudaram a eliminar este tipo de erros, embora ainda houvesse alguns erros l6gicos e de codificao no VSSP 10 antes dos testes e correcHes, Queforam rapidamente ultrapassados.
Como pode ser observado na figura as vias de comunicao para sinais so claramente indicadas em SDL~Os diagramas SDL tm a vantagem de apresentarem a estrutura e comunicaco de uma forma natural para Quea primeira vista paream desenhos informais frequentemente utilizados na descrio de sistemas. Na realidade expressam a definio e uso de nomes SDL e devem ser cuidadosamente definidos e ligados para Que a defini(;:8oSDL seja vaEda. Por exemplo Os parntesis rectos [,..] situados petto de uma seta no diagrama definem Os sinais transportados na direco da seta na via correspondente, e um nome entre parntesis curvos dentro dos [...] a notaco para uma lista de sinais definida algures nos diagramas. O SDT verifica se todos os sinais definidos na lista CPClsignals sAo sinais provenientes de CPCI (processo em ISUPType) estao incluidos na lista ISUP_PC, e podem ser recebidos por um processo dentro do bloco PC. Estes casos exemplificam verifica6es ( e as correspondentesmelhorias de engenharia) Queexistem com o SDL""88e com o SDT2.3.
O VSSP 2,0. cujo desenho orientado a objectos, apresenta algumas vantagens face ao VSSP I.0. O encaminhamento de sinais simplificado, pois o conjunto de processos para um circuito e encapsulado dentro de um bloco, declarado como um tipo e instanciado. Para a comunicao intrabloco Ossinais no tm de ser enviados para um processo de entre varios: ha uma instcia de cada ti-popor cada circuito. O SOL-88 no suportava a tipificao de blocos.
Os procedimentos remotos no SDL-92 proporcionam a realizao de uma funo remota de acesso seguro a dados, viabilizando uma especificao simplificada. Uma desvantagem Que a comunicaAo entre processos subjacente a essa funcionalidade n&o pol vezes 6bvia pela simples leitura da estrutura dos diagramas.
O VSSP 2.0 tambm utiliza o conceito de procedimento global do SDL-92 para o caso do procedimento Makelnst. Este procedimento muito simples e o mesmo em diversos processos, mas em SOL-88 tinha de ser declarado em cada processo O uso de outras abordagens para os objectos SDL (processos e procedimentos) a noco de armazem (package") Que esta em estudo actualmente. 0 uso de tipos fol considerado, mas no fol considerado pratico com SDT 3.0 devido ao facto de Que a ferramenta no suporta paretros de contexto.
Page 12 --, -
A expertncia de facto teve como principal preocupao a re-engenharia do desenho e da gerao de c6digo~pelo que a maior parte da informao transmitida pela experincia relevante para estas actividades. Os resultados mostraram claramente Queesta abordagem proporciona uma melhoria de produtividade real E rnelhoria de qualidade. 0 rigor na determinao de objectivos em cada projecto tambm uma outra vertente Quecertamente 6 beneficiada.
Algumas no\.idades (novos conceitos) do SDL-92 face ao SOL-88 t`oramja teis e permitirarn sirnplificac5es no VSSP 2~0~A ferramenta SDT3.O apresentou uma migrao suave da vetso VSSP I.0 realizada com base no SDT 2.3, acrescentando mais algumas novidades ao nivel da ferramenta hem como obviamente ao nivel da linguagem base.
Os melhorarnentos conseguidos pela utilizao do SDL-92, no foram to significatinos como os obtidos no salto inicial da implementao em C para a implementao em SDL-88~A razo para isso fica a cie\'Er-se a 1- Os desenhos do VSSP 1.0 foram a base de mais de 90% do VSSP 2.0 medida em Que se realizou uma migraco; 2- Um projecto de raiz poderia adequar-se mais a explorac.o das novas funcionalidades da linguagem; 3- Per outro lado, para fazer um uso completo da linguagem SOL-92 necessario efectuar um re-arranjo substancial nos desenhos originais baseadOs na normalizao existente nas telecomunica5es. Estes so baseados em SOL-88 informal luase scruple, 0 beneficio expectave} Selia a facilidade (e portanto a diminuio do custo) da manuteno, e re-utiliza80, mas este estudo esta fora do mbito deste trabalho. O sucesso da experincia teve ja como resultado Quefoi tomada uma deciso ja em curso para a utilizao do SOL/SDT para o re-desenho de um outro m6dulo do sistema CET-IN realizado previamente em C++: o S. Provavelmente, Se tambm este caso for um sucesso, Se podera seguir outro m6dulo (SCF). Outros projectos no CET poder5o tambem beneficial da aplicao do SDT: o projecto LONGA, tambem com o sistema operativo HP-UX, e o projecto ELD, com o Sistema operativo RMX. Algumas experincias ja foram realizadas neste tiItimo caso, com sucesso, para comprovar que era possivel gerar c6digo para um sistema operativo e Hardware diferentes do "host"
Page 13
Glossaty
ReferReins: Z.I O{,' ,"'93)"CCITT Specification and Description Language (SDL)" ITU-T, Geneva, 1994.
O. F r emand and R Reed `SOL: the Standard for Engineering Telecommunication Software" pp 38-47 in "Software Standards Symposium", IEEE Computer Society Press, Los Alamitos, CA 1993, ISBN 0-8186-4240-8.
J. Rumbaugh et, Al. "Object-Oriented Modelling and design`., Prentice-Half. 1991.