CHEN: The Entity Relationship Model: Toward a

Unified View of Data. ACM Trans, on Data Base Systems, Vol. 1, N. 1, 1976.

[10] R. EL MASRI, G. WIEDERHOLD: Data model integration using the structural model. Proc. ACM Sigmod Int. Conf. Boston, 1979.

[11] B. KAHN: A Structural Logical Data Base Design Metho­

dology PhD Thesis, University of Michigan, 1979.

[12] P. KANZIA, H. KLEIN: On the equivalence of databases in connection with normalization. Proc. Int.

Workshop on Formal Bases for Data Bases, Toulouse 1979.

[13] V. LUM et al. 1978: New Orleans Data Base Design Work­

shop. Report Proc. 5th Int. Conf. on Very Large Data Bases, Rio de Janeiro, 1979.

[14] S. NAVATHE et al.: Information Modelling tools for Data Base Design. Data Base Directions,Fort Lauderdale, 1980.

139

[15] S. NAVATHE, S. GADGIL: A methodology for view

integra-j_

I-tion in logical data base design. Proc. 8 Int.

Conf. on Very Large Data Bases, Mexico City 1 982.

[16] Proc. New York Symposium on Database Design, New York 1 978.

[17] T. TEOREY, J. FRY: Design of Database Structures, Prentice Hall 1982.

[18] D. TZICHRITZIS; P. LOCHOVSKY: Data Models. Prentice Hall 1982.

[19] M. TARDIEU, D. NANCI, D. PASCOT: Conception d'un Systeme d 'information - construction de la base de données, Edition d 'organization Paris

1 979.

BING YAO, V. WADDLE, B. HOUSEL: View Modelling and Integration Using the functional data model.

IEEE Trans, on Software Engineering, Vol. SE8, N. 6, 1982.

[20] S.

t A

SAS - A SPECIFICATION S U P P O R T SYSTEM

M ichel LISSANDRE, Pierre LAGIER, Ahmed SKALLI I G L — Institut de Génié L og icie l — Paris, France

♦ ♦ ♦ ♦ ♦ ♦ ♦

( ^ C o p y r ig h t IGL, 1982

ABSTRACT

The softw are crisis has shown the utmost im p o rta nce of building up any system developm ent on "g o o d " specifications.

SADT*, the w e ll-k n o w n S ofte ch's graphical m ethod has been applied to a broad spectrum of com plex system engineering problems. Perhaps because of its graphical a spe ct, the m ethod is not c u rre n tly fully autom ated by a tool which would be at once com plete, accessible, portable, and w hich w ould support the v a rie ty of w ays to p ra ctice SADT.

SAS, tool c u rre n tly developed by IGL aims a t becom ing such a tool. SAS a llow s to create and edit diagrams, to build "k its " , sets of diagrams w h ic h , by the bringing of a re a d e r/a u th o r c y c le procedure in to operation, assure q u a lity to implement this re a d e r/a u th o r c y c le , to m aintain the project files, to p e r­

form some s y n ta c tic and sem antic ch e cks, along w ith quality and p ro d u c tiv ity measurements.

The developm ents of this to o l, being of the increm ental ty p e , has led to a first release in February 1983 and w ill be pursued until 1985.

* SADT is a tradem ark of S ofte ch, USA & IGL, France.

142

1. B A C K G R O U N D

The cost of softw are developm ent and m a intenance, the im pact of analysis and design errors, and the shortcom ings of traditional analysis and design approaches have brought abo u t a so ftw a re crisis.

Until re c e n tly , softw are professionals responsible for analysing users' require­

ments and designing com puter based system s have had to spend a significant am ount of time creating a t once the analysis and design approaches to be used, th e environm ent in w h ich to bring them into operation, as well as sol­

ving th e te ch n ica l problems at hand.

Sofware engineering is a disciplined and controlled approach that deals w ith many k e y problems associated w ith so ftw a re developm ent. The fra m e -w o rk is established by a uniform system life c y c le th a t incorporates the standard procedures and docum entation th a t are necessary for analysis, design, and im plem entation a ctivitie s. U nderlying this standardization is the successful a p p lica tio n of a variety of tools and techniques tha t ta ke advantage of the principles of structuring.

During th e last decade, research has co n ce n tra te d on techniques for defining, ana lysin g , and docum enting the requirem ents for systems. Many of these te c h ­ niques com plem ent other s tru ctu re d techniques in the system development life c y c le such as structured program m ing. The objective of structures analysis is to p rovide a m ethodical app ro a ch for docum enting system requirements and analysing the in teg rity of the requirem ents. The essential pu jose is to th o ro u g h ly evaluate the needs and requirem ents w hich the sys em must satisfy, com m only called problem d efin itio n , preceding the a c tu a l design and im plem en­

tation phases of the system developm ent life cyc le .

M anual structured analysis techniques are very e ffe c tiv for small problem d e fin itio n a ctivities. The m agnitude of the cre a tion , m ru ite n a n c e , an„; review of large problem definitions has made it p ra c tic a l to '.evelop com puter-aided support tools.

/

143

3

-H ow ever, the existing tools deserve one or more remarks am ong the follow ing :

♦ They are dedicated to a p a rticu la r typ e of softw are (process control, m anagem ent,...) or to a p a rtic u la r type of specification (perform ance ana­

lysis, sim ulation, im plem entation, static d escriptio n ,...).

♦ They are only used by so ftw a re professionals.

♦ There is only one w ay to operate them .

♦ The specifications they generate are d iffic u lt to understand and even read, w hich makes their control by n o n -sp e cialists almost impossible.

Of course, these tools may be ve ry useful in the ir own app lica tio n domain, but it is a commonly made m istake to e xpe ct them to provide more than w hat they can do, or to fulfill a d iffe re n t purpose tha n the one th e y have been de­

signed for.

The tool we shall present differs from those m entioned above in the following points :

♦ It must be e a s y -to -le a rn and e a s y -to -u s e , thus, n on-specialists, and of course n o n -so ftw a re professionals (custom ers, users, m anagers,...) will benefit of its use.

♦ It must cope with various w ays of p ra cticing the supported specification m ethod. Specifying and designing com plex systems is a c re a tive process.

Two analysts may then com e to similar results by different m eans, even w ithin the strict bounds of a rigorous, disciplined m ethod, if the tool does not allow each analyst to follow his w a y of th in k in g , it w ill not be used, or w ill be misused by this analyst, with all the n e g a tive consequences.

♦ It must support the analysis and sp ecificatio n of all kinds of systems : softw are system s, embedded systems, but also systems where com puters play only a marginal role, or even are com pletely missing : "P3 systems" (P aper, People, Procedures). It must allow to sp ecify at various abstraction levels and from various view points.

144

♦ It must — last b u t not least — provide a solution to th e major problem of any specification : its legibility by people of various skills. It must allow and m ake it easier to com m unicate the specifications betw e e n all the partners involved in any big p ro je c t. The specifications produced w ith this tool must be found as clear, re adable, understandable, checkable and verifiable by the "u p stre am "

intervening p arties (custom ers, operators and va rio u s users, main c o n tra c to r,...) as by the "d o w n s tre a m " ones (su b con tra cto r, designers, implementers, m ainte­

nance te a m s,...).

2. S A D T

Softech has developed a m ethodology to deal w ith these problems, know n as SADT (S tru cture d Analysis and Design Technique) and, together w ith a few European com panies (1GL being one of those fo r the French speaking European and A frica n countries), offers licensing, tra in in g , and consulting assistance in its use.

SADT supplies its manual user w ith a good a nsw er to the last three points referred to a b o v e .

Today, hundreds of projects and thousands of a na lysts have used SADT all over the w o rld . Hence it is very like ly that the re a d e r of this paper already know s SADT. H e /s h e should the n skip this c h a p te r w here the major concepts will be briefly described, highlighting the features w h ich will impose specific functions to a supporting tool.

Since its deve lo p m en t, SADT has been presented in various papers [R O ^ S -T ó ], [ RO SS-77a], [ R O SS-77b], [D IC KO VER -77], [C O N N O R -80] in w hich the re a ­ der can find a dd itio n al inform ation. This paper o nly gives a sum m ary, highly based upon [R O S S -7 6 ] and [CO NNO R-80].

SADT is a m ethodology developed by Douglas T. Ross in 1974 th a t is useful for system p lanning, requirem ents analysis, and system design. It was created to provide a rigorous, disciplined approach to a c h ie v e understanding of user’s

145

needs prior to providing a design solution. SADT did not evolve from a design te c h n iq u e , but rather was developed by exam ining the problems associated w ith defining system requirem ents. It is generally not used for so ftw a re module (program ) detailed design because SADT does not contain the co nstru cts neces­

sary for program design (sequence, se le ction , and Iteration).

SADT provides the user, the system a n a lyst, and the system designer with a diagram m ing technique to structure tfye products of analysis ana design,

*

a set of m ethods to structure the procedures of perform ing analysis and design, and a set of management and human fa c to rs to stru cture the overall process of analysis and design.

There are seven fundam ental c o n ce p ts underlying SADT :

♦ Complex problem s are best a tta c k e d by building a model w h ic h expresses an in -d e p th understanding of w h a t the problem is and w hich is su ffic ie n tly precise to serve as the basis fo r the problem solution.

♦ Analysis of any problem should be to p -d o w n , m odular, h ie rarchic and stru c­

tured.

♦ The model should be represented by a diagram m ing technique w h ich shows com ponent p arts, their interfaces, and how they compose a h ie rarchic structure.

♦ The m o d el-bu ildin g technique must represent both things (o b je c ts , documents or data) and happenings (a ctivitie s perform ed by m en, m achines, com puters, s o ftw a re ). The model must show both aspects properly related.

♦ The analyst should d ifferentiate as m uch as p ra cticab le betw een an initial fu n ctio n a l m odel of functions to be perform ed and a subsequent design of model of how those functions w ill be perform ed.

♦ Analysis methods must support disciplined, coordinated te a m w o rk.

♦ Ali analysis and design decisions and com m ents thereon must be in w ritten form and available for open review by all team members.

146

- 6

-A natural la n gu a ge is not precise enough to express requirem ents and system designs and to ensure c o s t-e ffe c tiv e system developm ent. Natural languages tend to be v e rb o s e , redundant, and subject to in terpreta tion . Therefore, in order to ta k e a d va n ta g e of the principles of s tru c tu rin g , it is im perative that we should em ploy a graphic technique that focuses on displaying a ctivitie s and data, a llo w s the gradual introduction of d e ta il, and is suitable for show ing inform ation in a to p -d o w n manner.

Using a graphic technique to explain requirem ents or a system design involves developing a m odel. A model is a representation of reality —an "expression of one thing w e hope to understand in terms of a no the r we th in k we do under­

stand" [W EINBERG-75].

A SADT m odel is an organized sequence of diagram s. A h ig h -le v e l overview diagram represents the whole subject. Each lo w e r-le v e l diagram shows a lim i­

ted amount of d e ta il about a w e ll-co n stra in e d to p ic . Further, each lo w e r-le v e l diagram c o n n e c ts e xa ctly into the model to represent the w hole system , thus preserving the lo g ical relationship of each com ponent to the to ta l system (See figure 1).

Figure 1 —H ierarchical Structure of SADT Diagrams

147

5ADT analyses tw o major aspects of each system — its data and its a ctivitie s.

This is done by aeveloping tw o com plem entary m odels, an a c tiv ity decom posi­

tion and a data decom position. The a c tiv ity decom position details the happenings as a c tiv ity boxes, while show ing the things th a t in terre late them as data arrows.

The data decom position details th e things of the system as data boxes, with the happenings that interrelate them shown as a c tiv ity arrows.

Each SADT model consists of diagram s made up of three to six boxes, and arrow s. On an a c tiv ity diagram w ith in an a c tiv ity m odel, the boxes represent a c tiv itie s , and the arrow s represent data. It is just th e opposite on data diagrams.

On an a c tiv ity diagram , a box is nam ed with a v e rb . The le ft-h a n d side of the box is used to show input d a ta , labelled w ith a noun, to be transform ed by the a c tiv ity : the incom ing data flo w . The rig h t-h a n d side of the box shows output data, w hich is data transform ed by the a c tiv ity tha t is to be used else­

w here, that is, outgoing data flo w .

Unlike other diagramm ing tec h n iq u e s , SADT also describes control and sup­

porting m echanisms. The top of th e box is used to show control d a ta , w hich are data th a t constrain the ope ra tio n of an a c tiv ity . This inform ation has tw o major purposes. First, the d is tin c tio n betw een input and control allow s the system analyst or designer to e x p lic itly show data th a t are not transform ed into output, and the re fo re, are used to m odify th e behavior of an a c tiv ity . Second, the intro du ctio n of c o n tro l data allow s the analyst or designer to evaluate the cohesiveness and fu n c tio n a l representation of all of the boxes on a diagram. If all relationships w ere truly in p u t/o u tp u t, procedural coupling w ould be the only degree of stre ng th that could be evaluated [M Y E R S -7 5 ].

Constraint relationships must be show n in order to distinguish betw een the degrees of binding and to allow a Q ualitative e va lua tio n of the decom position to be perform ed.

On an a c tiv ity diagram , the b o tto m of the box is used to show a supporting mechanism of the a c tiv ity . That is, if the analyst or system designer wishes to describe organizations th a t perform a given a c tiv ity , the mechanism arrow is used to identify the dep a rtm e nt, section, or e ven the individual th a t is res­

ponsible for the a c tiv ity . A nother e xtrem ely im portant use of the mechanism side of the box is for c ro s s -re fe re n c in g models.

148

An example of a SADT diagram is show n in Figure 2.

U S E D a : C A T £ • V O •? K ? ; G D A T E C O N T E X T

P R C . E C T R E V Ü P A F T t

• R g r O M M E N O E t

’h---N O T E S 1 2 3 4 5 6 7 8 3 1 0 !C \ T :0N

NOOE irT T C Í: ' "IS Ü M ä T «

A0 RUN F A R '.!

Figure 2 — SADT A c tiv ity Diagram

The final step in the modeling process is to tie to g e th e r the a c tiv ity and the data portion. Each decom position is ch ecke d to m ake sure that its use of dual elements is co herent. This process reduces errors and oversights and assures consistency in fu rth e r w ork.

No one person can com pletely understand every aspect of a com plex system w ithin the time limits usually im posed. Even if this w ere possible, it w ould place an undesirable dem and upon one person. Analysis requires disciplined, co o rd i­

nated team work. Consequently the insights and vie w s of project personnel must be com m unicated e ffe ctive ly a t every step and level of analysis to insure tha t the SADT m odels reflect the best thinking of the team . Adequacy and

149 i

i-quality must be assured by regular, c ritica l re v ie w , so th a t changes and c o rre c ­ tions can he made on an increm ental e volutionary basis.

Because SADT starts w ith single black box and proceeds to increasingly de­

tailed diagrams of elements of the problem , docum entation becomes available on a continuous basis. At each step decisions can be seen In co nte xt and challenged w hile a lte rn a tive approaches are a va ila b le . The docum entation provides the basis for decisions and vastly im proves the visibility of the pro­

je c t to the team and to m anagem ent.

C ooperative team w ork demands a clear definition of the types or interactions w hich should o c c u r betw een the staff in vo lved . SADT a n ticipa tes this need by establishing title s and fun ctio ns of appropriate roles.

Throughout a p ro je ct the draft versions of the diagram s produced are distri­

buted to other p ro ject members for review and com m ent. SADT requires that each person m aking com m ents about a diagram w ill m ake them in w riting and submit them to the auth or of the diagram . Such an approval cycle co n ­ tinues upw ard in the organizational structure until th e diagrams and eventually the entire m odel are o fficially a c c e p te d .

A SADT librarian provides filin g , distribution, re c o rd -k e e p in g support, and pre­

cise control o ver the status of the evolving model. Since e verything is on re­

co rd , future enhancem ent and system m aintenance can refer to p re vio u sly- take n decisions.

3. S A S (from the French " Systeme d 'A id e ä la S p e cifica tio n")

SAS takes adva n ta g e of the solutions brought up by SADT to the problem m entioned in ch ap ter 1, mainly the com m unication problem , but provides its user with a set of additional fa cilitie s :

- training aids ;

— com puter assisted draw ing ;

150

— autom atic controls and v e rific a tio n of : . conform ance to 5ADT basic rules,

. co herence of boxes, a rrow s and labels w ithin a diagram , . co herence of diagrams w ith in a model,

. co herence of models w ithin a project ;

— program design aids ;

— com plexity measurements ;

— p ro d u ctivity measurements ;

SADT, as supported by SAS is the standard SADT as developed by S oftech, and as used since. Its wide usage m akes it now possible to consider SADT as a "standard". B ecause of this w ide usage, SAS has been designed to be highly portable so th a t organizations using equipm ents ranging from top scale micros (on local n e tw o rk s or not) to big main fram es, may ben e fit from its use.

The functions SAS perform s are — c h a rity begins a t home —expressed by the SADT diagrams show n in Figure 3 to 7.

How ever, SAS' m ajor points are being discussed in the follow ing paragraphs.

This section deals w ith the functions represented by the follow ing boxes of the model :

— Create kits (Diagram AO, box 2)

- C riticize kits (diagram AO, box 2)

— Handle m odels (Diagram AO, box 4)

(more sp e cifica lly : Supply users w ith docum ents (Diagram A4, box 3) 3.1. Creating and editing diagram s

(more sp e cifica lly : . Create a new diagram

. O btain inputs from e xte rn a l authors . Update diagrams

(Diagram A l , box 2) (Diagram A l , box 3) (Diagram A l , box 4) )

1 MTEr?V 1 EW NOTES_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

TECHN ICO- COMMERCIAL DOCUMENTS_ _ _ _ _ _ _

EXTERNAL P I A C - ■r3 H M £ N T S .REACTIONS

M A NAGERS A TECHNICAL COMM. D I RECTIVES

n - T E A M OBJE C T I V ES

ASSIST S.A.D.T, USERS

DIAG R A M S .C O M M EN T S . RE A C T IONS

PROJECT DOCUME N T AT I O N

ME AS U R E M EN T S A CHECKS

WOE UD > S A S / A - 0 _{r im «} A S S I S T S « A , P • T . U S E R S NUMERO <

151

152

C ljVTF .AI GÜ-'F'TtVFS

«OU'D . S A S / A 0 T1TRE * A S SIST S . A . D . T U S E R S NUMERO i

»aeuD > S A S / A 1 IHRE . C R E A T E K I T S numero *

153

154

S A S / A 4 IURE i H A N D L E M O D E L S NUMERO

#

woEUD ’ S A S / A 5 IHRE * M E S U R E AND V E R I F Y NUMERO >

155

156

The legibility criterion

SADT syn ta x rules are precise but not very num erous. Therefore the SADT author has som e freedom of a c tio n when draw ing diagrams. V\ithin the bounds set by the ru le s, he has to strain a fte r the highest readability. To this end, he may set out boxes, arrow s and labels "a t b e st". The method gives guide­

lines for this draw ing process, but the a u th o r’ s perception —conscious or unconscious — of the clarity of his diagram and of the understandability of his message also plays a large part.

SAS does not hinder the a u th o r from creating cle a r diagrams. To a certain extent, SAS enhances even diagram c la rity , from the first step, w hen the first draft em erges from the previous ske tch e s, to the last ones, w hen the draft e vo lve s w ith the various com m ents and revisions. SAS has been de­

SAS does not hinder the a u th o r from creating cle a r diagrams. To a certain extent, SAS enhances even diagram c la rity , from the first step, w hen the first draft em erges from the previous ske tch e s, to the last ones, w hen the draft e vo lve s w ith the various com m ents and revisions. SAS has been de­

In document Kecskemét, HungaryTanulmányok 150/1983 May 22-27. 1983 "S D M " HUNGARIAN ACADEMY OF SCIENCES COMPUTER AND AUTOMATION INSTITUTE (Pldal 140-169)