0% found this document useful (0 votes)
2 views

IS2Lecture3

The document discusses various methodologies and software tools for the analysis and design of information systems, focusing on techniques such as SADT, FAST, UML, OMT, and MERISE. It outlines the principles, graphical representations, and advantages and disadvantages of these methods, emphasizing their applications in creating databases that accurately reflect real-world scenarios. Additionally, it details the structured approach of MERISE for implementing IT projects, including the study, diagnosis, and design of systems.

Uploaded by

donkengmichael2
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
2 views

IS2Lecture3

The document discusses various methodologies and software tools for the analysis and design of information systems, focusing on techniques such as SADT, FAST, UML, OMT, and MERISE. It outlines the principles, graphical representations, and advantages and disadvantages of these methods, emphasizing their applications in creating databases that accurately reflect real-world scenarios. Additionally, it details the structured approach of MERISE for implementing IT projects, including the study, diagnosis, and design of systems.

Uploaded by

donkengmichael2
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 16

IS2L3: Methodology and software tools

INTRODUCTION
Actually, the analysis and design of information systems has most of the time vocation to allow the creation of
databases, which must represent as closely as possible the reality of the field studied thus requiring the use of a
design method. The scenario for designing can be presented like this:

I. General presentation of the different methodologies


Many methods are used to come out with the new system ranging from functional methods such water fall, agile,
spiral etc. to more object-oriented methods such as SADT, Merise, OMT, or UML. We have already seen some
procedural method so let’s examine some object-oriented ones.

1. SADT: Structured Analysis and Design Technique


SADT (Structured Analysis and Design Technique) is a method that permits to analyze a system by dividing it to
elementary functions to describe the technical solution to implement. It is useful to define user’s need for an IT
development, and also to describe the industrial processes and procedures. In the present article, I’ll try to explain
the concept of SADT.
Principle
It is a method that helps engineers to describe and understand systems, it can be used in many engineering fields
(Electrical, Electronics, Software…). It is based on the schematization of analysis in a top-down approach using
boxes to represent entities and activities, and arrows to refer to the relations between entities. It allows to describe
systems from global to more detailed levels. The basic element in this method is: Box + Arrows.
Graphical construction
The analysis is done graphically and uses a decomposition with a top-down approach. To do this, we use box that
should be in a determined context, and they are related to other boxes by arrows that represent constraints between
them. The diagram can represent two models: data and activity.
IS2L3: Methodology and software tools

Box is represented by a rectangle contains:


• A verb to determine the activity
• A label Aijk to mention the activity: Aijk is a child of Aij that
is the child of Ai
Arrows can be incoming or outgoing:

• Case activity model


o Inputs enter from the left of box to represent data
needed by the activity
o Outputs exit from the right of box to represent
results (the product) of activity
o Controls from the top of box to represent constraints to accomplish activity, they are not consumed
o Mechanisms to represent means and eventual tools to accomplish activity
• Case data model, three types of arrows:
o Inputs to represent activities to produce data
o Outputs to represent consume the data
o Controls to represent constraints influencing datas
This following schema illustrates the concept:

The big advantage of this method is its structured and hierarchical presentation that allows to decompose and
analysis the complex systems, but it presents also some disadvantages: No presentation for the logical operators,
and the sequences. It helped to give rise to other methods and it was implemented by different software.
IS2L3: Methodology and software tools

2. FAST: Function Analysis System Technique


The FAST method or the Function Analysis System Technique, is a method used by the engineer to transform
the product services functions to technical functions. The method proposes an interrogative approach to find
solution by finding responses to the famous questions «What?When?and How?».
Principle
It is another functional analysis method that helps to describe and to interpret complex systems. It starts by a
principal function that will be decomposed to component functions, that can be also decomposed to elementary
functions. The analysis go from the More General (MG) to the More Detailed (MD).
It adapts an interrogative approach:
• From MG to MD: it helps to find the way to construct the solution. (How?)
• From MD to MG: it helps to justify the choice used to construct the solution. (Why?)
Graphical construction
The method has a graphical representation. To represent a function we use a rectangle containing a verb
describing the function. The flow of information is an arrow, it can be:
• Input arrow to describe data or constraint
• Output arrow to give results of the function (data or constraint for an other eventual function).
An arrow can be unique or combined with other arrows by the logical operators OR and And. The following
picture illustrates the principle :

For more details, we can release a FAST digram for any elementary function. It helped to give rise to other
methods and it was implemented by different software. FAST is a practical method for professionals and also
engineering students to understand the working methods.

II. Detail analysis with Object Oriented methodologies (UML, MERISE)


1. UML: Unified Modeling Language
UML is a way of visualizing a software program using a collection of diagrams. The notation has evolved from
the work of Grady Booch, James Rumbaugh, Ivar Jacobson, and the Rational Software Corporation to be used
for object-oriented design, but it has since been extended to cover a wider variety of software engineering projects.
IS2L3: Methodology and software tools

Today, UML is accepted by the Object Management Group (OMG) as the standard for modeling software
development. UML stands for Unified Modeling Language. UML 2.0 helped extend the original UML
specification to cover a wider portion of software development efforts including agile practices.

• Improved integration between structural models like class diagrams and behavior models like activity
diagrams.
• Added the ability to define a hierarchy and decompose a software system into components and sub-
components.
• The original UML specified nine diagrams; UML 2.x brings that number up to 13. The four new diagrams
are: communication diagram, composite structure diagram, interaction overview diagram, and timing
diagram. It also renamed state chart diagrams to state machine diagrams, also known as state diagrams.
Principle
The key to making a UML diagram is connecting shapes that represent an object or class with other shapes to
illustrate relationships and the flow of information and data.
The current UML standards call for 13 different types of diagrams: class, activity, object, use case, sequence,
package, state, component, communication, composite structure, interaction overview, timing, and
deployment organized into two distinct groups: structural diagrams (Class diagram, Package diagram, Object
diagram, Component diagram, Composite structure diagram, Deployment diagram) and behavioral or
interaction diagrams (Activity diagram, Sequence diagram, Use case diagram, State diagram, Communication
diagram, Interaction overview diagram, Timing diagram).

➢ Class Diagram
Class diagrams are the backbone of almost
every object-oriented method, including
UML. They describe the static structure of a
system.

➢ Package Diagram

Package diagrams are a subset of class


diagrams, but developers sometimes treat
them as a separate technique. Package
diagrams organize elements of a system into
related groups to minimize dependencies
between packages.

➢ Object Diagram
Object diagrams describe the static structure of a system at a particular time. They can be used to test class
diagrams for accuracy.
IS2L3: Methodology and software tools

➢ Composite Structure Diagram

Composite structure diagrams show the internal part of a class.

➢ Use Case Diagram


Use case diagrams model the functionality of a system using actors and use cases.

➢ Activity Diagram
Activity diagrams illustrate the dynamic nature of a system by modeling the flow of control from activity to
activity. An activity represents an operation on some class in the system that results in a change in the state of the
system. Typically, activity diagrams are used to model workflow or business processes and internal operation.
IS2L3: Methodology and software tools

➢ Interaction Overview Diagram


Interaction overview diagrams are a
combination of activity and sequence
diagrams. They model a sequence of
actions and let you deconstruct more
complex interactions into manageable
occurrences. You should use the same
notation on interaction overview diagrams
that you would see on an activity diagram.

➢ Timing Diagram
A timing diagram is a type of behavioral or
interaction UML diagram that focuses on
processes that take place during a specific
period of time. They're a special instance
of a sequence diagram, except time is
shown to increase from left to right instead
of top down.

➢ Communication Diagram
Communication diagrams model the
interactions between objects in sequence.
They describe both the static structure and
the dynamic behavior of a system. In many
ways, a communication diagram is a
simplified version of a collaboration
diagram introduced in UML 2.0.

➢ Component Diagram
Component diagrams describe the organization of physical software components, including source code, run-time
(binary) code, and executables.

➢ Deployment Diagram
Deployment diagrams depict the physical resources in a system, including nodes, components, and connections.

➢ Sequence Diagram
Sequence diagrams describe interactions among classes in terms of an exchange of messages over time.
➢ State Diagram
Statechart diagrams, now known as state machine diagrams and state diagrams describe the dynamic behavior of
a system in response to external stimuli. State diagrams are especially useful in modeling reactive objects whose
states are triggered by specific events.
IS2L3: Methodology and software tools
IS2L3: Methodology and software tools

There are many different types of UML diagrams and each has a slightly different symbol set. Class diagrams are
perhaps one of the most common UML diagrams used and class diagram symbols center around defining
attributes of a class. For example, there are symbols for active classes and interfaces. A class symbol can also be
divided to show a class's operations, attributes, and responsibilities. Visibility of any class members are marked
by notations of: + (for Public), - (for Protected), # (for Protected), / (for Derived) and ~ (for Package).
Lines are also important symbols to denote relationships between components. Generalization and Inheritance
are denoted with empty arrowheads. Composition is shown with a filled in diamond. Aggregation is shown with
an empty diamond. Dependencies are marked with a dashed line with an arrow. Using << >> allows you to
indicate properties of that dependency. Multiplicity is usually shown with a number at one end of the arrow and
a star (*) at the other.

Package diagrams have symbols defining a package that look like a folder. Activity diagrams have symbols for
activities, states, including separate symbols for an initial state and a final state. The control flow is usually shown
with an arrow and the object flow is shown with a dashed arrow. Use case diagrams have symbols for actors and
use cases.

2. OMT: Object Modeling Technique


OMT is a predecessor of the Unified Modeling Language (UML). Many OMT modeling elements are common
to UML

3. MERISE: Méthode d’Etude et de Réalisation des Systèmes d’Entreprise


MERISE proposes steps for the implementation and conduct of IT projects. MERISE is an acronym signifying
Method of Studies and Realizations for Computer Systems for Companies (English translation), is the commonly
and widely used for the study and design of database in France.
This method aims to replace a manual system of an organization by an automated system of information
processing. It aims, firstly to demonstrate the potential problems of the existing system and, secondly, to make
improvements to the system. The factors considered in the study are the capture, collection, storage, processing
and transmission of information.
So, MERISE helps to undertake a study of the existing and move on to the actual design, if that is the solution,
i.e. it proceeds as follows:
1. Study of the existing: Here one describes the existing structure that wants to say the real situation of the
organization and how it functions.
2. Diagnosis and criticism of the existing: What the problem is and how to improve the situation.
IS2L3: Methodology and software tools

3. Design and setting up of the new system: to propose the models that lead to the database or even to propose
some interfaces and programming codes for the realization while using certain programming languages and
management system of databases. To create the models, MERISE proceeds by the system of 3 carvings on 4
Levels (figure1).
Schema comments
Note that the steps and sub-steps of the MERISE approach are in line with the direction of the different arrows
whose steps and sub-steps are linked to the preceding ones by several well-defined principles of cohesion and
validation of the models represented by circles numbered in figure1, this consolidates the data processing.
As shown in the under graphic, the MERISE has two major steps for designing a database: Study, diagnosis and
criticism of the existing and Design and implementation of new system.
IS2L3: Methodology and software tools
IS2L3: Methodology and software tools

1 Models of the conceptual level


1.1 The conceptual communication model
Definition of domains: domains are defined by grouping elementary functions. The objective is to verify that a
function is only executed by a domain and that every function is executed by a domain so that a better definition
of the field of study is obtained. In the initial version of Merise, this term designates a "management domain",
with a meaning not very well defined: are the activities grouped together the same "nature", or do they cooperate
to the same "goal"? Now, we accept as "domain (study)" any subsystem of the company which could have a sub
information system.
Definition of partners: Partners are systems or functional actors external to the company.
Messages description: The description of messages between domains or between domain and partner specifies
the requests or responses exchanged necessary for the operation of the system. Conceptual messages are written,
oral or even implied.

Vocabulary enlighten: The CCM information are explained. The removal of synonyms, polysemes (words with
multiple meanings) and the description of calculation rules, composite or equivalent information allow to define
a first "data dictionary" allowing a clarification and definition of data. The vocabulary used by computers and
the user should not contain ambiguity.
1.2 The conceptual treatment model
The CTM describes the treatments carried out by domain (conceptual operation). He validates CCM messages
and describes the conditions for transmitting results messages.
IS2L3: Methodology and software tools

1.3 The conceptual data model


It specifies the concepts (entities) handled by the user and the links between these concepts (relationships).
Information is carried by entities and relationships.

1.4 Validation between communications and data


Make sure the message’s information are found in the data model, either directly (on an entity or a relationship),
either by a computation rules, a equivalence or compound information.
1.5 Data / treatments validation
Every operation (treatment) must have a read data model (from memorized data) and often a write (save
information); any data necessary for a treatment must be accessible. If an information is missing, it must be added
to the data model. This is the validation of data by treatments. All entities, relationships, and information in the
data model must be created and viewed by an operation. Otherwise, the information is useless or an operation is
missing. At that moment, you have to delete the information or create the operation (mean to access). This is the
validation of data treatments.

2 Models of the organizational level


2.1 The communication organizational model
It describes the exchange of information between sites or work stations. Firstly, the structure or organizational
chart of the company is drawn. It can be useful to draw the exchanges organized before the CCM if the user has
any difficulty to understand the functional view. It can describe IT-messages between sites: request from a
workstation (client), for programs to launch, data requests or data to update on another site (server).
IS2L3: Methodology and software tools

2.2 The treatment organizational model


The TOM describes who does what. The organization chart, the definition of workstations (entities) and their
"relationships" must precede the procedures. A procedure requires an exhaustive description of all the operations
to be carried out, and the special operations for some exceptional situations.

2.3 The data organizational model


It corresponds to the conceptual data model site by site of "information system " (that is for each subsystem). The
designer defines the workstations, the organized messages, the message supports are defined, access rights…
Here is an example of an organizational concept. An authorization from (XXX) is given to a user or a group of
users.
IS2L3: Methodology and software tools

At this stage, the volumes (size of the database) are calculated according to how many occurrences of individuals,
what are the average and maximum cardinalities, the lengths of the information, the total volume of characters in
the database? 0N 0N relationships containing information is taken into account.
The lengths of the information are usually as 20 characters for labels, 20 for addresses and 6 for dates. The lengths
identifiers depend on the number of occurrences. If 4,000 occurrences exist, the length of the identifier will be 4
(number of digits of the number of occurrences).
Volumes are calculated from DOM. This calculation is approximated. He does not hold disregard the optimization
of the database, relations containing no information transformed into a recording when switching from DOM to
DPM and index files. During the preliminary study, only the DOM is built. MPD must then be optimized by the
database administrator. That is why all volumes are calculated from DOM. A multiplier coefficient should then
be applied to the result (to ensure database approximated size will not exceed) .

3 Models of the logic level


3.1 The architecture of the information system
This model, not included in Merise, and also called application model, describes IT architecture of the project. It
describes the computer applications involve, the messages exchanged (whose size are calculated), and the shared
databases.
the architecture makes it possible to detect the interface tools and what can be reused from the existing
IS2L3: Methodology and software tools

3.2 The treatment logical model to be validated by the user


The user must validate the sequence (order) of screens display before it validates the information content
displayed or to be entered for each state.

3.3 The data logical model


The logical data model is built from DOM with respect to some rules and then optimized by the database
administrator or DBA in English, depending on volumes and access frequencies read and write data. No DCM or
DOM is subject to optimization.
3.4 The treatment logical model to be constructed
Once the DLM and the external specification of the tools have been validated, the designer describes the actions
for updating the database, obtaining the information, conditions for changing from one state to another, displayed
on the next state or belonging to a constraint on a state. The objective of this model is to build a guide to
programming loads.
To properly optimize the database, it is necessary to describe all the actions of read and write to the base records,
their frequency and their consequences on treatment times depending on the different cases optimization
(redundancy of information, grouping or breakdown records) and therefore data structures. The step would take
much more time and space to build that solution.
IS2L3: Methodology and software tools

III. Evaluation of the cost


Project management concept is applied in modern organizations in almost all branches of the economy. Project
management implies goal balancing in terms of scope, time and costs that arise during its accomplishment. Project
costs management is a process necessary for project accomplishment within certain budget; therefore, the project
managers have to define the project well, estimate the time and costs in a realistic manner. There are various types
of costs in the course of the execution of the project, some of them direct, others indirectly connected to the
execution of the project. Four project cost management processes are (PMI, 2007): cost management planning,
cost estimation, budget setting and cost control.
Most frequently used methods and techniques in cost estimate are: analogous estimate, bottom-up
estimating, resource cost rate parameter modeling, suppliers’ offer and reserve analysis, project
management software. The analogous estimate uses real costs of the previous similar projects as a foundation
for cost estimation in the current project. It implies the expert knowledge, as well as the similarities of the projects
compared. The bottom-up estimates are based on the assessment of individual activities and their
summing up at the level of the entire project. The most common reasons of incorrect project cost estimate are:
estimates are performed quickly, lack of experience in estimations, underestimation of certain types of costs, the
efforts to get a large contract or internal funds. Considering that many projects do not develop according to plans,
new or altered cost estimates are necessary, with the aim of finding alternative solutions. The problems are even
more complex in organizations that simultaneously implement several projects or investments as a set of
interrelated activities integrated in the portfolio.

IV. Usage of software tools in conceiving and developing the software


The used of software such as WINDEV, WEBDEV, Android Studio, Adobe Creative suite and frameworks
to easily create efficient web, desktop or android application has become the technique used nowadays by many.
Indeed, these software are human like languages and therefore easy to understand and work with even if the user
is not really computer literate. For some of these tools coding is not needed and everything can be done from a
smooth graphical user interface.
➢ Creating a database with WINDESIGN software

You might also like