Chapter 5: System

Ministry Design
of Higher Methodologies
Education By: Mr. Nyambi
Republic Blaise
of Cameroon
IUGET, Bonamoussadi – Douala Peace – Work – Fatherland
Department of Computer Engineering Academic Year 2019/2020
&

INFORMATION SYSTEMS
Level: HND1 Lecturer: Mr. Nyambi Blaise
Options: Software Engineering & Network

Lesson objectives

It is expected that after going through this lesson, you would be able to

- Design a system using UML & MERISE

- Draw diagrams to represent UML & MERISE systems
- Normalize the data conceptual models
- Design a system using SADT

Table Of Contents
CHAPTER FIVE – SYSTEM DESIGN METHODOLOGIES .............................................................. 3
1.1 INTRODUCTION ................................................................................................................................. 3
1.2 MERISE METHOD .............................................................................................................................. 3
1.2.1 DATA DICTIONARY ..................................................................................................................... 3
1.2.2 Data Dictionary Typical Attributes ............................................................................................. 3
1.2.3 Examples of Data Dictionaries ............................................................................................... 4
1.2.4 ADVANTAGES OF MERISE................................................................................................... 5
1.2.5 DISADVANTAGES OF THE MERISE METHOD ................................................................. 5
1.2.6 MERISE LEVELS ..................................................................................................................... 6
1.2.6.1 Conceptual Level ................................................................................................................. 6
1.2.6.2 Organizational Level ............................................................................................................ 6
1.2.6.3 Logical Level ........................................................................................................................ 6
1.2.6.4 Physical Level ...................................................................................................................... 6
1.2.7 MERISE – The Data Conceptual Model (DCM) ....................................................................... 6
1.2.7.1 Entities ................................................................................................................................ 7
1.2.7.2 Properties............................................................................................................................ 7
1.2.7.4 Identifier.............................................................................................................................. 8

C H A P T E R 5 – S y s t e m M e t h o d o l o g i e s P a g e 1 | 30
Chapter 5: System Design Methodologies By: Mr. Nyambi Blaise

1.2.7.5 Associations and Cardinalities ............................................................................................ 8

1.2.7.6 Normalisation Rules .......................................................................................................... 12
1.2.8 Data Logical Models (DLM) ................................................................................................. 12
1.2.8.1 Tables, Columns And Rows ............................................................................................... 12
1.2.8.2 Primary And Foreign Keys Of Each Table .......................................................................... 12
1.3 UML ................................................................................................................................................. 14
1.3.1 ADVANTAGES OF UML ............................................................................................................. 15
1.3.2 DISADVANTAGES OF UML ........................................................................................................ 15
1.3.3 UML Object-Oriented Concepts ............................................................................................... 16
1.3.4 UML Diagrams And Their Descriptions .................................................................................... 17
1.3.4.1 Activity Diagram ................................................................................................................ 18
1.3.4.2 Use Case Diagram ............................................................................................................. 19
1.3.4.3 Interaction Overview Diagram .......................................................................................... 20
1.3.4.4 Sequence UML Diagram .................................................................................................... 21
1.3.4.5 Class Diagram .................................................................................................................... 21
1.3.4.6 Object Diagram ................................................................................................................. 22
1.3.4.7 Component Diagram ......................................................................................................... 24
1.3.4.8 Deployment Diagram ........................................................................................................ 24
1.3.5 SADT METHOD ............................................................................................................................. 26
a) Advantages of SADT Method: ............................................................................................... 27
b) Disadvantages of SADT Method: .......................................................................................... 27
1.3.6 OMT METHOD .......................................................................................................................... 27
1.3.7 Software To Draw UML & MERISE Diagrams ............................................................................... 28
1.3.8 Revision Questions ....................................................................................................................... 28
1.3.8.1 Practical Exercises ................................................................................................................. 28
1.3.8.2 UML Questions...................................................................................................................... 28

C H A P T E R 5 – S y s t e m M e t h o d o l o g i e s P a g e 2 | 30
Chapter 5: System Design Methodologies By: Mr. Nyambi Blaise

CHAPTER FIVE – SYSTEM DESIGN METHODOLOGIES

1.1 INTRODUCTION
A methodology by definition is a body of methods used in a particular activity
according to Irny, S.I. and Rose, A.A. (2005). According to “Oxford Advanced learners’
dictionary (8th edition)” is a particular way of doing or carrying out something. In Information
System Design, there are several methodologies which can be used to design a system.
Software design methodology provides a logical and systematic means of proceeding with the design
process as well as a set of guidelines for decision-making. The design methodology provides a
sequence of activities, and often uses a set of notations or diagrams.
There are several methods of designing an application thus we can quote amongst
others the MERISE, UML, SDT, Object Oriented method. MERISE & UML are two methods
are mostly used in the educational and industrial system. Each of these methods has its
advantages and also its disadvantages.

1.2 MERISE METHOD

MERISE is a French acronym, «Méthode de Recherche Informatique pour les Systèmes d'Entreprise».
It is a method of analysis, design and IT project management. Merise proceeds to separate treatment
of data and processes, where the data-oriented view is modelled in three stages, from conceptual,
logical through to physical. This methodology uses data dictionary to represent data.

1.2.1 DATA DICTIONARY

A data dictionary, or metadata repository, as defined in the IBM Dictionary of
Computing, is a "centralized repository of information about data such as meaning,
relationships to other data, origin, usage, and format". Oracle defines it as a collection of
tables with metadata. The term can have one of several closely related meanings pertaining to
databases and database management systems (DBMS):

 A document describing a database or collection of databases

 An integral component of a DBMS that is required to determine its structure
 A piece of middleware that extends or supplants the native data dictionary of a DBMS

1.2.2 Data Dictionary Typical Attributes

Here is a non-exhaustive list of typical items found in a data dictionary for columns or fields:

 Entity or form name or ID. The group this field belongs to.
 Field name, such as RDBMS field name
 Displayed field title. May default to field name if blank.
C H A P T E R 5 – S y s t e m M e t h o d o l o g i e s P a g e 3 | 30
Chapter 5: System Design Methodologies By: Mr. Nyambi Blaise

 Field type (string, integer, date, etc.)

 Dimension(s) such as min and max values, display width, or number of decimal places.
 Field display order or tab order
 Coordinates on screen (if a positional or grid-based UI)
 Default value
 Prompt type, such as drop-down list, combo-box, check-boxes, range, etc.
 Is-required (Boolean)
 Is-read-only (Boolean)
 Reference table name, if a foreign key. Can be used for validation or selection lists.
 Various event handlers or references to. Example: "on-click", "on-validate", etc.
 Format code, such as a regular expression or COBOL-style "PIC" statements
 Description or synopsis

1.2.3 Examples of Data Dictionaries

Example 1 : Entity is Student
No. NAME DESCRIPTION TYPE SIZE REQUIRED PK or FK NULL
1 Stu_id Student’s ID Integer 10 Y FK Not Null
2 Stu_reg Student’s Matricule Varchar 8 Y PK Not Null

3 Stu_name Student’s Name Varchar 50 Y Not Null

4 Stu_dob Date of Birth Date Y Not Null

5 Stu_phone Phone Number Integer 9 Y Not Null
Example 2 : Entity is Client
No. NAME DESCRIPTION TYPE SIZE REQUIRED PK or FK NULL
1 id Client’s ID Integer 10 Y PK Not Null
2 Email Client’s Email Varchar 50 N Null

3 Name Client’s Name Varchar 50 Y Not Null

4 Password Client’s Password Varchar 32 Y Not Null

5 Phone Phone Number Integer 9 Y Not Null

C H A P T E R 5 – S y s t e m M e t h o d o l o g i e s P a g e 4 | 30
Chapter 5: System Design Methodologies By: Mr. Nyambi Blaise

Figure 1 MERISE Model

1.2.4 ADVANTAGES OF MERISE

 Is more in tune with the reality of systems development
 Offers flexibility to adapt method to suit the circumstances of the particular situation
 Gain advantages of a structure/ framework without excessive rigidity
 Could prove to be more cost effective
 Could encourage creativity and innovation

1.2.5 DISADVANTAGES OF THE MERISE METHOD

 No integrating philosophy: just a set of methods, tools and techniques
 Difficulty in training new systems analysts
 Lack of standardization
 Difficult to maintain

C H A P T E R 5 – S y s t e m M e t h o d o l o g i e s P a g e 5 | 30
Chapter 5: System Design Methodologies By: Mr. Nyambi Blaise

1.2.6 MERISE LEVELS

1.2.6.1 Conceptual Level

The conceptual level is to design the SI disregarding all technical and organizational
constraints and these both in terms of data treatment.
The conceptual level answers the question What? (On what to do, what with data).
The MERISE methodology used is:
 The Data Conceptual Model (DCM).
 The Treatment Conceptual Model(TCM)

1.2.6.2 Organizational Level

The organizational level's mission is to integrate the analysis criteria related to the
organization studied. The organizational level will define the notions of temporality,
chronology of operations of unity of place, will define the workstations, access to data bases.

The questions at the level of treatment are:

 Who?
 Where?
 When?
The MERISE methodology used is:
 The Data Organizational Model (DOM).
 The Treatment Organizational Model of Treatment (TOM).

1.2.6.3 Logical Level

Logic is independent of hardware, programming languages and data management. This is the
answer to the question What with?
The methodology will:
 The Data Logical Model (DLM).
 The Treatment Logic Model (TLM).

1.2.6.4 Physical Level

The physical level defines the actual organization (physical) of data. It provides technical
solutions, such methods of storage and access to information. This is the answer to the
question What?
The methodology used is:
 The Data Physical Model (DPM).
 Physical Treatments and Operational Model (PTOM)

1.2.7 MERISE – The Data Conceptual Model (DCM)

The DCM is based on entity concepts and association and on the concepts of
relationships. Graphing, simple and accessible, allowing a non-IT to participate in its
C H A P T E R 5 – S y s t e m M e t h o d o l o g i e s P a g e 6 | 30
Chapter 5: System Design Methodologies By: Mr. Nyambi Blaise

development. The basic elements of a conceptual data model are: Properties, Entities and
Relationships. Let’s take an example of a system that has to do with an online web portal.

1.2.7.1 Entities
The entity is defined as a management object considered of interest to represent the
activity model (e.g user entity) and each entity carries one or more simple properties.

The establishment of this portal requires the following entities:

1.2.7.2 Properties
The properties describe the entities.

C H A P T E R 5 – S y s t e m M e t h o d o l o g i e s P a g e 7 | 30
 Chapter 5: System Design Methodologies By: Mr. Nyambi Blaise

1.2.7.4 Identifier
One of these properties has a specific role, it is also known as the key identifier. The
identifier is used to find a unique way all the properties involved in the entity. Identifiers are
also called keys and most used are primary and foreign keys.

1.2.7.5 Associations and Cardinalities

The association is a semantic link between one or more entities: the association can be
reflexive, preferably binary, and ternary sometimes or even higher dimension.

The association is enriched by the notion of cardinality, cardinality also sometimes refers to
the relationships between tables. Cardinality between tables can be one-to-one, many-to-
one or many-to-many. it indicates the minimum and maximum number of times any
occurrence of an entity can participate in an association, and we can have:

a) Minimum Cardinality
- 0 if an occurrence of the entity may exist while not interfering in any occurrence of the
association
- 1 an occurrence of the entity can exist only if it occurs in at least one occurrence of the
association
- N: Rare cases to avoid

b) Maximum cardinality
- 1 if an occurrence of the entity cannot be involved in more than one occurrence of the
association.

C H A P T E R 5 – S y s t e m M e t h o d o l o g i e s P a g e 8 | 30
Chapter 5: System Design Methodologies By: Mr. Nyambi Blaise

- N whether an instance of the entity cannot be involved in more than one occurrence of the
association

1.2.7.5.1 Understanding Associations and Cardinalities

0..1(read as “0 or 1”) : One-to-one relationship. Used for Minimum
0..* (read as “0 or N”) : Many-to-many relationship
1..1: One-to-many relationship
1..* : Many-to-many relationship. Used for maximum
1.2.7.5.2 Some Points to Note
 Cardinalities are composed of 2 values; min and max.
 Always read from rectangle(entity) to ellipse(relation)
 A relation occurrence always touch exactly one occurrence of each entity it touches.
 Although any cardinality specification is possible, always use: 0 or 1 for minimum and 1 or N
for maximum.

Examples:

C H A P T E R 5 – S y s t e m M e t h o d o l o g i e s P a g e 9 | 30
Chapter 5: System Design Methodologies By: Mr. Nyambi Blaise

C H A P T E R 5 – S y s t e m M e t h o d o l o g i e s P a g e 10 | 30
Chapter 5: System Design Methodologies By: Mr. Nyambi Blaise

The diagram below demonstrates the ER-Diagram of IUGET whereby all the entities are being
displayed alongside their cardinalities.

C H A P T E R 5 – S y s t e m M e t h o d o l o g i e s P a g e 11 | 30
Chapter 5: System Design Methodologies By: Mr. Nyambi Blaise

1.2.7.6 Normalisation Rules

This is about the rules to be observed the relationship entity association to be valid.
Normalisation of names
The name of an entity, his attributes and the name of the association between the entities
must be unique. Two entities can't have the same attribute name.
Normalisation of identifier
A good identifier should avoid too much attributes, and should have the lesser number of
characters as possible.
Normalisation of attributes
It is recommended to avoid entities with too many attributes by replacing those attributes
with associations.
Normalisation of attributes of associations
The associations attributes must directly depend of the identifiers of the table that the
association link.

1.2.8 Data Logical Models (DLM)

The DLM is the normal result of MERISE process. Its purpose is to bring us closer to
the physical model. For this, we start from the Conceptual Data Model and the relationships
we remove it within certain pre-established rules.

The LDM provides technical vocabulary again that it is important to understand well.

1.2.8.1 Tables, Columns And Rows

So that was an entity Data Conceptual Model is a table in the DLM. Thus this table is
organized in line or column and each column represents the fields of the table and each line
represents the values for each field.

1.2.8.2 Primary And Foreign Keys Of Each Table

The identifier that had the DCM, DLM is the primary key which can be recognized by
its underlining. Also a table can contain the primary key of another table that at that moment
becomes a foreign key. Which foreign key is symbolized by a sharp before his name. Thus:

 A table has only one primary key, but can have multiple foreign keys;
 The foreign key can be made;
 The column of the primary key cannot be empty;
 The foreign key can also be primary key in the table.

C H A P T E R 5 – S y s t e m M e t h o d o l o g i e s P a g e 12 | 30
Chapter 5: System Design Methodologies By: Mr. Nyambi Blaise

C H A P T E R 5 – S y s t e m M e t h o d o l o g i e s P a g e 13 | 30
Chapter 5: System Design Methodologies By: Mr. Nyambi Blaise

1.3 UML
UML is a general purpose modeling language in the field of software engineering. The
basic level provides a set of graphic notation techniques to create visual model of object
oriented software- intensive system. Higher level represents cover processing design oriented
view of a system. It was developed by Grady BOOCH, Ivar JACOBSON and James
RUMBAUCH at rational software in 1990s. It was adopted by the Object Management Group
(OMG) in 1997, and has been managed by this organization ever since. It is an Object-Oriented
design methodology.
UML is graphic language; it is therefore based on the utilization of diagrams
(13 in total). These diagrams are organized in view. A view being a means to describe a system
following data angle, at each view corresponds the diagram UML. UML modelises a system
according to three axes or view which are: the functional view, the dynamic view and the
static view. We can observe on the diagram below the modeling of those three axes (the
diagrams in bracket are those who will keep our attention in each view)

Figure 2 The Three Axes of UML

C H A P T E R 5 – S y s t e m M e t h o d o l o g i e s P a g e 14 | 30
Chapter 5: System Design Methodologies By: Mr. Nyambi Blaise

Today UML is the standard of the widely used object oriented modeling in computer
engineering. There are 14 diagram types which can be divided into two main categories:
structural diagram and behavioral diagram as show on the figure below

Figure 3 UML Diagrams

1.3.1 ADVANTAGES OF UML

 Independence with respect to any programming language,
 Powerful support of communication,
 Implementation of all the richness of the approach object,
 Description of all the models of the analysis to the realization of the software,

1.3.2 DISADVANTAGES OF UML

 The semantics of UML is not formalized. It is specified by using the natural language,
 Difficult optimization of the choice of the classes,
 The relations between the various categories of diagrams are not formalized,
 Implementation the practical of UML is not intuitive,
 UML does not provide any methodological guide

C H A P T E R 5 – S y s t e m M e t h o d o l o g i e s P a g e 15 | 30
Chapter 5: System Design Methodologies By: Mr. Nyambi Blaise

1.3.3 UML Object-Oriented Concepts

UML can be described as the successor of object-oriented (OO) analysis and design.

An object contains both data and methods that control the data. The data represents the state
of the object. A class describes an object and they also form a hierarchy to model the real-
world system. The hierarchy is represented as inheritance and the classes can also be
associated in different ways as per the requirement.

Objects are the real-world entities that exist around us and the basic concepts such as
abstraction, encapsulation, inheritance, and polymorphism all can be represented using UML.

UML is powerful enough to represent all the concepts that exist in object-oriented analysis
and design. UML diagrams are representation of object-oriented concepts only. Thus, before
learning UML, it becomes important to understand OO concept in detail.

Following are some fundamental concepts of the object-oriented world −

 Objects − Objects represent an entity and the basic building block.

 Class − Class is the blue print of an object.
 Abstraction − Abstraction represents the behavior of an real world entity.
 Encapsulation − Encapsulation is the mechanism of binding the data together and
hiding them from the outside world.
 Inheritance − Inheritance is the mechanism of making new classes from existing
ones.
 Polymorphism − It defines the mechanism to exists in different forms.

C H A P T E R 5 – S y s t e m M e t h o d o l o g i e s P a g e 16 | 30
Chapter 5: System Design Methodologies By: Mr. Nyambi Blaise

1.3.4 UML Diagrams And Their Descriptions

UML diagrams are resumed in the figure below

Figure 4 UML Diagrams and Their Description

C H A P T E R 5 – S y s t e m M e t h o d o l o g i e s P a g e 17 | 30
Chapter 5: System Design Methodologies By: Mr. Nyambi Blaise

1.3.4.1 Activity Diagram

Activity diagrams are probably the most important UML diagrams for doing business
process modeling. In software development, it is generally used to describe the flow of
different activities and actions. These can be both sequential and in parallel. They describe
the objects used, consumed or produced by an activity and the relationship between the
different activities. All the above are essential in business process modeling.

C H A P T E R 5 – S y s t e m M e t h o d o l o g i e s P a g e 18 | 30
Chapter 5: System Design Methodologies By: Mr. Nyambi Blaise

1.3.4.2 Use Case Diagram

A cornerstone part of the system is the functional requirements that the system fulfills. Use
Case diagrams are used to analyze the system’s high-level requirements. These requirements
are expressed through different use cases. We notice three main components of this UML
diagram:

 Functional requirements – represented as use cases; a verb describing an action

 Actors – they interact with the system; an actor can be a human being, an
organization or an internal or external application
 Relationships between actors and use cases – represented using straight arrows

1.3.4.2.1 Differences between <<Include>> and <<Exclude>

The include relationship is intended for reusing behaviour modeled by another use case,
whereas the extend relationship is intended for adding parts to existing use cases as well as for
modeling optional system services

Include = reuse of functionality (i.e. the included functionality is used or could be used
elsewhere in the system). Include therefore denotes a dependency on another use case.

Extends = adding (not reusing) functionality and also any optional functionality. Extends
therefore can denote one of two things:
1. adding new features/capabilities to a use case (optional or not)
2. any optional use cases (existing or not).

Summary:
Include = reuse of functionality
Extends = new and/or optional functionality

C H A P T E R 5 – S y s t e m M e t h o d o l o g i e s P a g e 19 | 30
Chapter 5: System Design Methodologies By: Mr. Nyambi Blaise

From the above use case, view items extends add items to cart, but “viewing an item is
optional after adding it to cart, hence we extend”.

Checkout includes Make purchase, this is because in order to make a purchase, you MUST
checkout, hence include is compulsory and make purchase is dependent on checkout.

1.3.4.3 Interaction Overview Diagram

Interaction Overview UML diagrams are probably some of the most complex ones. So far we
have explained what an activity diagram is. Additionally, within the set of behavioral
diagrams, we have a subset made of four diagrams, called Interaction Diagrams:

 Interaction Overview Diagram

 Timing Diagram
 Sequence Diagram
 Communication Diagram

C H A P T E R 5 – S y s t e m M e t h o d o l o g i e s P a g e 20 | 30
Chapter 5: System Design Methodologies By: Mr. Nyambi Blaise

1.3.4.4 Sequence UML Diagram

Sequence diagrams are probably the most important UML diagrams among not only
the computer science community but also as design-level models for business application
development. Lately, they have become popular in depicting business processes, because of
their visually self-explanatory nature.

As the name suggests, sequence diagrams describe the sequence of messages and interactions
that happen between actors and objects. Actors or objects can be active only when needed or
when another object wants to communicate with them. All communication is represented in a
chronological manner. To get a better idea, check the example of a UML sequence diagram
below.

1.3.4.5 Class Diagram

Class UML diagram is the most common diagram type for software documentation.
Since most software being created nowadays is still based on the Object-Oriented
Programming paradigm, using class diagrams to document the software turns out to be a
common-sense solution. This happens because OOP is based on classes and the relations
between them.

In a nutshell, class diagrams contain classes, alongside with their attributes (also referred to
as data fields) and their behaviors (also referred to as member functions). More specifically,
each class has 3 fields: the class name at the top, the class attributes right below the name, the
class operations/behaviors at the bottom. The relation between different classes (represented
by a connecting line), makes up a class diagram.

C H A P T E R 5 – S y s t e m M e t h o d o l o g i e s P a g e 21 | 30
Chapter 5: System Design Methodologies By: Mr. Nyambi Blaise

The example above shows a basic class diagram. The ‘Checkings Account’ class and the
‘Savings Account’ class both inherit from the more general class, ‘Account’. The inheritance
is shown using the blank-headed arrow. The other class in the diagram is the ‘Client’ class.
The diagram is quite self-explanatory and it clearly shows the different classes and how they
are interrelated.

1.3.4.6 Object Diagram

When we discuss structural UML diagrams, we have no choice but to delve deeper into
computer science-related concepts. In software development, Classes are considered abstract
data types, whereas objects are instances of the abstract class. For example, if we have a class
“Car” which is a generic abstract type, then an instance of the class “Car” would be an
“Audi”.

Object UML diagrams help software developers check whether the generic abstract structure
that they have created (class diagram), represents a viable structure when put into practice,

C H A P T E R 5 – S y s t e m M e t h o d o l o g i e s P a g e 22 | 30
Chapter 5: System Design Methodologies By: Mr. Nyambi Blaise

i.e: when the objects of a class are instantiated. Some developers see it as a secondary level of
accuracy checking.

The object UML diagram above is based on the class diagram we showed earlier. It depicts
instances (objects) of the classes we created earlier. To be more precise, the general class
‘Client’, now has an actual client called “James”. James is an instance of the more generic
class and it has the same attributes, however with given values. The same thing has been done
with the Checkings and Savings account. They are both objects of their respective classes.

Do you notice any mistake? Take a look at the class diagram example. You can notice that
the attributes ‘account_number’ and ‘routing_number’ are different for the Checkings and
Savings account. As a result, it makes more sense to put those attributes in their respective
classes, rather than in the more generic class ‘Account’.

Additionally, we notice that we do not use the attributes ‘wire_routing_number’ and ‘bic’.
This is an indicator that something could be wrong in the design of our system. Perhaps we
don’t require them in this specific example, thus allowing us to keep the old structure.
However, there is a good chance that there is a design flaw which must be resolved

immediately.
C H A P T E R 5 – S y s t e m M e t h o d o l o g i e s P a g e 23 | 30
Chapter 5: System Design Methodologies By: Mr. Nyambi Blaise

1.3.4.7 Component Diagram

A component diagram is essentially a more specialized version of the class diagram—the same
notation rules apply for both. A component diagram breaks a complex system down into smaller
components and visualizes the relationship between those components.

1.3.4.8 Deployment Diagram

Deployment diagrams are used to visualize the relation between software and hardware. To
be more specific, with deployment diagrams we can construct a physical model of how
software components (artifacts) are deployed on hardware components, known as nodes.

A typical simplified deployment diagram for a web application would include:

 Nodes (application server and database server)

 Artifacts (application client and database schema

C H A P T E R 5 – S y s t e m M e t h o d o l o g i e s P a g e 24 | 30
Chapter 5: System Design Methodologies By: Mr. Nyambi Blaise

The nodes host the artifacts. The database schema runs on the database server and the
application client runs on the application server.

As the name suggests, the deployment diagram shows exactly where each software
component is deployed.

C H A P T E R 5 – S y s t e m M e t h o d o l o g i e s P a g e 25 | 30
Chapter 5: System Design Methodologies By: Mr. Nyambi Blaise

1.3.5 SADT METHOD

Structured Analysis and Design Technique (SADT) is a method of American origin,
developed by Doug Ross in 1977. It was introduced in Europe since 1982 by Michel Galiner.
SADT is a methodology of functional analysis and the most known methodology of project
management. It does not only allow the project management developers to describe the tasks
of the project and their interaction, but also to describe the system which the project aims to
study, create or modify. John Mylopoulos (2004). Conceptual Modelling III. Structured Analysis and
Design Technique (SADT). Retrieved 21 September 2008

SADT has been developed and field-tested during the period of 1969 to 1973 by Douglas T.
Ross and SofTech, Inc. The methodology was used in the MIT Automatic Programming Tool
(APT) project. It received extensive use starting in 1973 by the US Air Force Integrated
Computer Aided Manufacturing program.

According to Levitt (2000) SADT is "part of a series of structured methods, that represent a
collection of analysis, design, and programming techniques that were developed in response to
the problems facing the software world from the 1960s to the 1980s. In this timeframe most
commercial programming was done in COBOL and Fortran, then C and BASIC. There was
little guidance on “good” design and programming techniques, and there were no standard
techniques for documenting requirements and designs. Systems were getting larger and more
complex, and the information system development became harder and harder to do so. As a
way to help manage large and complex software.

SADT was among a series of similar structured methods, which had emerged since the 1960
such as:

 Structured programming in circa 1967 with Edsger W. Dijkstra.

 Structured design around 1975 with Larry Constantine and Ed Yourdon
 Structured analysis in circa 1978 with Tom DeMarco, Yourdon, Gane & Sarson,
McMenamin & Palmer.
 Information engineering in circa 1990 with James Martin.

C H A P T E R 5 – S y s t e m M e t h o d o l o g i e s P a g e 26 | 30
Chapter 5: System Design Methodologies By: Mr. Nyambi Blaise

In 1981 the IDEF0 methodology was published, based on SADT.

As a method of functional analysis and the most known management of the projects, SADT
presents strong points and weak points.

a) Advantages of SADT Method:

 Its simplicity
 Its adequacy to capture the user's needs
 Its capacity with being able to produce solutions on several levels of abstraction.

b) Disadvantages of SADT Method:

 Its analysis is concentrated much on the functions, the coherence of the data being
neglected
 The rules of decomposition are not explicit. The decomposition differs according to
analysts'
 Its difficulties of taking account of the non-hierarchical interactions in the complex
systems
 Lastly, the volatility of the functions makes that the system is in perpetual D-design

1.3.6 OMT METHOD

OMT is an object modeling language for software modeling and designing. The
methodology consists of building a model of the system and then adding implementation details
during its design. It describes Object model or static structure of the system. A fundamental
assumption of OMT is that object-oriented thinking represents a more natural and intuitive way
for people to reason about reality. As a general modeling approach, OMT may be used to model
all types of work. Terje Totland (1997). 5.2.7 Object Modeling Technique (OMT) Thesis, Norwegian
University of Science and Technology (NTNU), Trondheim.

Advantages of OMT Disadvantages of OMT

 OMT is a fast and intuitive approach for  OMT’s primary weakness is its lack of
identifying and modeling all objects that make an explicit mechanism to capture timing
up the system. constraints and real-time issues.

C H A P T E R 5 – S y s t e m M e t h o d o l o g i e s P a g e 27 | 30
Chapter 5: System Design Methodologies By: Mr. Nyambi Blaise

 The systems designed using OMT are closer to  OMT lacks a comprehensive
real world as the real world functioning is architecture as it doesn’t take into
directly mapped into the system. Thus making consideration the testing phase of the
it easier to produce and understand design. software development cycle.
 The dynamic behavior of objects within a  The syntax of the models is not well
system can be described using OMT dynamic defined. Sharing of model components
Model. among different models or versions of a
model is not clear.

Hint: Master all the 14 UML Diagrams and when and how to use them. Also master how to draw
them.

1.3.7 Software To Draw UML & MERISE Diagrams

 Win’Design
 PowerAMC
 E-Draw
 Power Designer

1.3.8 Revision Questions

1.3.8.1 Practical Exercises
1. For a library management system, draw the various MERISE & UML diagrams.
2. Draw the UML Diagrams for a student management system in IUGET.
3. Consider a small local shop in the quarter, draw its system design diagrams using any
methodology of your choice.

1.3.8.2 UML Questions

1. With the use of diagrams, differentiate between extend and include in UML.
2. What is/are the most important UML diagram(s) to a software engineer?
3. Why would you choose to use the UML methodology over the MERISE
methodology?
4. Why would you choose to use the MERISE methodology over the UML
methodology?
5. Can a class diagram show the dynamic behaviour of a system?
6. Can deployment diagram be used for forward and reverse engineering?
7. Can it be used for forward and reverse engineering?
8. Can it represent parallel flow of activities?
9. Can we convert statechart diagram to activity diagram?
10. Can we use forward engineering in component diagram?
11. Can we use the use case diagram for forward and reverse engineering?
C H A P T E R 5 – S y s t e m M e t h o d o l o g i e s P a g e 28 | 30
Chapter 5: System Design Methodologies By: Mr. Nyambi Blaise

12. Describe the purpose of use case diagram?

13. How object oriented concepts are related to UML?
14. Is component diagram representing the dynamic view of a system?
15. Name major building blocks of UML?
16. Name some scenarios where object diagrams are used?
17. Name the three mechanisms in stereotype?
18. What are the artifacts of a deployment diagram?
19. What are the artifacts used to make a component diagram?
20. What are the different UML diagrams?
21. What are the different elements of a use case diagram?
22. What are the different modeling used in UML?
23. What are the elements of an object diagram?
24. What are the goals of UML?
25. What are the main usages of a deployment diagram?
26. What are the notations used in behavioural things?
27. What are the notations used in relationships?
28. What are the notations used in structural things?
29. What are the other four diagrams used in UML for capturing dynamic behaviour of a
system?
30. What are the structural diagrams and behavioural diagrams?
31. What are the usages of sequence and collaboration diagram?
32. What do you mean by dynamic behaviour of a system?
33. What does an object diagram capture?
34. What is OO analysis?
35. What is OO design?
36. What is a Statechart diagram?
37. What is a class diagram?
38. What is a constraint rule?
39. What is a deployment diagram?
40. What is a node?
41. What is a reactive system?
42. What is a state?
43. What is a use case diagram?
44. What is an activity diagram?
45. What is an event and how it influences the states of an object?
46. What is an interaction diagram?
47. What is an object diagram?
48. What is collaboration diagram?
49. What is component diagram?
50. What is composition and aggregation?
51. What is difference between analysis and design?
52. What is generalization and when it is used?
53. What is meant by isomorphic?
54. What is responsibility of an object?
55. What is role of UML in OO analysis and design?
56. What is sequence diagram?
57. What is static and dynamic view of a system?
C H A P T E R 5 – S y s t e m M e t h o d o l o g i e s P a g e 29 | 30
Chapter 5: System Design Methodologies By: Mr. Nyambi Blaise

58. What is structural diagram?

59. What is the difference between a class diagram and an object diagram?
60. What is the difference between a flow chart and an activity diagram?
61. What is the difference between aggregation and composition?
62. What is the difference between sequence and collaboration diagram?
63. What is the interaction diagrams used in UML?
64. What is the main usage of a Statechart diagram?
65. What is the main usage of an activity diagram?
66. What is the only grouping thing available in UML?
67. Why conceptual model is important?
68. Why statechart diagram us used?

See: SOFTWARE REQUIREMENT SPECIFICATION DOCUMENT for more practicals

C H A P T E R 5 – S y s t e m M e t h o d o l o g i e s P a g e 30 | 30