Lecture 6

Introduction
To
Analysis Modeling
And
Data Modeling

1
2
 Contents
• What is modeling
• Analysis modeling
• Purpose of analysis modeling
• Analysis rules of thumb
• Analysis modeling approaches
• Elements of analysis modeling
• Diagram of element of analysis modeling
• Structure of analysis modeling
• Three aspects of analysis modeling
• Data modeling definition
• Data modeling overview 3
 (Cont…)
• Data modeling concept and example
• Approaches to data modeling
• How data model deliver benefits

4
 What is modeling?
• Modeling is a concept fundamental for software
engineering

5
 Analysis modeling
• The analysis model consist of a wide variety of
diagrammatic forms used to bridge an important gap

System Design System information

Description Model System behavior

System function

Analysis Model

6
 Purpose

• Describe what the customer wants to built.

• Establish the foundation for the software design.
• Provide a set of validation requirements.

7
 Analysis rules of thumb
• Make sure all points of view are covered
• Every element should add value
• Keep it simple
• Maintain high level of abstraction
• Focus on the problem domain
• Minimize system coupling

8
 Umbrella Activities of Analysis
In analysis modeling, umbrella activities refer to the high-level activities that encompass
and support the entire analysis process. They provide a framework for organizing and
managing the various tasks and deliverables involved in analysis modeling.
Here's a brief explanation of umbrella activities in analysis modeling:
1. Requirements Elicitation: This activity involves gathering information and
understanding the needs, expectations, and constraints of stakeholders. It includes
techniques like interviews, workshops, surveys, and observation to capture
requirements effectively.
2. Requirements Analysis: This activity focuses on analyzing the gathered
requirements to identify inconsistencies, conflicts, and ambiguities. It involves
techniques such as requirements prioritization, requirements traceability, and
requirements validation to ensure the requirements are complete, consistent, and
feasible.
3. Domain Modeling: Domain modeling involves creating a conceptual representation
of the problem domain. It includes identifying relevant concepts, relationships, and rules
that govern the domain. Techniques like class diagrams, entity-relationship diagrams,
or domain-specific languages may be used.
9
4. Use Case Modeling: Use case modeling focuses on capturing the functional
requirements of the system from the users' perspective. It involves identifying actors,
use cases, and their interactions to describe the system's behavior. Use case
diagrams and use case descriptions are commonly used artifacts.

5. Data Modeling: Data modeling involves representing the structure and

organization of data within the system. It includes identifying entities, attributes, and
relationships to design an efficient and effective database schema. Techniques like
entity-relationship diagrams or class diagrams can be used for data modeling.

6. Behavioral Modeling: Behavioral modeling focuses on capturing the dynamic

aspects of the system, including how it responds to events and executes processes.
Techniques like activity diagrams, sequence diagrams, or state machine diagrams
can be used to model system behavior.

These umbrella activities provide a holistic approach to analysis modeling, ensuring

that all necessary aspects are considered and addressed during the analysis phase of
a project. 10
 Analysis modeling approaches
Object Oriented Model
Models data element
Structured Analysis Models analysis classes
• Attribute • Data
• Relationship • Processes
Models processes that Models class collaborations
transform data

Techniques from both approaches are typically used

in practice. 11
 Elements of the analysis
model
1. Scenario based element
2. Class based elements
3. Behavioral elements
4. Flow oriented elements

12
 Scenario based element
• This type of element represents the system user point
of view.
• Scenario based elements are use case diagram, user
stories.

13
 Class based elements
• The object of this type of element manipulated by the system.
• It defines the object, attributes and relationship.
• The collaboration is occurring between the classes.
• Class based elements are the class diagram, collaboration
diagram Class based elements.

14
 Behavioral elements
• Behavioral elements represent state of the system and how it
is changed by the external events.
• The behavioral elements are sequenced diagram, state
diagram.

15
 Flow oriented elements
• An information flows through a computer-based system it
gets transformed.
• It shows how the data objects are transformed while they
flow between the various system functions.
• The flow elements are data flow diagram, control flow
diagram.

16
Diagram of Elements of analysis
model
Scenario based Element Class based Element
•Use case diagram •Class diagram
•User stories •Collaboration diagram

Analysis Model

Behavioral based element Flow oriented element

•Sequence diagram •Data flow diagram
•State diagram •Control flow diagram

17
Structure of analysis model

18
 Three aspects of analysis
modeling
• Data Modeling
• Functional Modeling
• Behavioral Modeling

19
 Data Modeling Definition
• Data modeling in software engineering is the process of
creating a data model for an information system by
applying formal data modeling techniques.

OR

• Data modeling is the process of exploring what kind of

data needs to be stored and then creating data
structures accordingly

20
 Data modeling overview
• A data model visually represent the nature of
data ,business rules governing the data and how it will
be organize in the database.
• A data model is comprised of three parts logical
design,conceptual design and physical design.
• Data models are created either in top-down approach or
bottom-up approach.
• In top-down ,data models are created by understanding
and analyzing business requirements.
• In bottom-up ,data models are created from existing
database , which has no data models
21
 Data modeling concept
• Analysis modeling starts with the data modeling.
• The software engineer defines all the data object that proceeds within
the system and the relationship between data objects are identified.
• In data modeling concept we have:
• Data object
• Data attribute
• Relationship
• Cardinality
• Modality

22
 Data objects
• The data object is the representation of composite
information.
For example, Height is a single value so it is not a valid
data object, but dimensions contain the height, the width
and depth these are defined as an object.

23
 Data attribute and
Relationship
Data Attributes
• Each of the data object has a set of attributes.
Relationship
• Relationship shows the relationship between data
objects and how they are related to each other.

24
 Cardinality
• Cardinality state the number of events of one object related to the
number of events of another object.
The cardinality expressed as:
One to one (1:1)
One event of an object is related to one event of another object.
For example, one employee has only one ID.
One to many (1:N)
One event of an object is related to many events.
Many to many(M:N)
Many events of one object are related to many events of another
object.

25
 Modality
• Modality describes whether a relationship between two or
more entities is needed or not. Thus, in the case of
modality, the modality can be classified into two types
namely nullable modality and non−nullable modality.

26
 Example
• The concept of data modeling can be better understood if we
compare the development cycle of a data model to the construction
of a house
• For example company ABC is planning to built a guest house and it
calls the building architect and projects its building requirements .
• Building architect develops the plans and give it to company ABC.
• Finally company ABC calls civil engineers to construct the guest
house.

27
Approaches to data modeling
• Conceptual Data Modeling
• Logical Data Modeling
• Physical Data Modeling

28
 Conceptual Data Modeling
• identifies the highest-level relationships between
different entities.

29
 Logical Data Modeling
• Illustrates the specific entities, attributes and
relationships involved in a business function. Serves as
the basis for the creation of the physical data model.

30
 Physical Data Modeling
• Represents an application and database-specific
implementation of a logical data model.

31
How data model deliver benefits

32
 Analysis Principles
• The functions that the software is to perform must
be defined.
• The behavior of the software (as a consequence
of external events) must be represented.
• The models that depict information, function, and
behavior must be partitioned in a manner that
uncovers detail in a layered (or hierarchical)
fashion.
• The analysis process should move from essential
information towards implementation detail.
 Analysis Principles...
• By applying these principles, the analyst approaches a
problem systematically.
• The information domain is examined so that function
may be understood more completely.
• Models are used so that the characteristics of function
and behavior can be communicated in a compact
fashion. Partitioning is applied to reduce complexity.
• Essential and implementation views of the software
are necessary to accommodate the logical constraints
imposed by processing requirements and the physical
constraints imposed by other system elements.
 Analysis Principles...
• Understand the problem before you begin to create the
analysis model. There is a tendency to rush to a solution,
even before the problem is understood. This often leads to
elegant software that solves the wrong problem!
• Develop prototypes that enable a user to understand how
human/machine interaction will occur. Since the
perception of the quality of software is often based on the
perception of the “friendliness” of the interface, prototyping
(and the iteration that results) are highly recommended.
• Record the origin of and the reason for every requirement.
This is the first step in establishing traceability back to the
customer.
 Analysis Principles...
• Use multiple views of requirements. Building data, functional,
and behavioral models provide the software engineer with
three different views. This reduces the likelihood that
something will be missed and increases the likelihood that
inconsistency will be recognized.
• Rank requirements. Tight deadlines may preclude the
implementation of every software requirement. If an
incremental process model is applied, those requirements to
be delivered in the first increment must be identified.
• Work to eliminate ambiguity. Because most requirements are
described in a natural language, the opportunity for ambiguity
abounds. The use of formal technical reviews is one way to
uncover and eliminate ambiguity.
 Information Domain
• All software applications can be collectively called data processing.
– Software is built to process data, to transform data from one form to
another; that is, to accept input, manipulate it in some way, and
produce output.
– This fundamental statement of objective is true whether we build
batch software for a payroll system or real-time embedded software
to control fuel flow to an automobile engine.
• It is important to note, that software also processes events. An event
represents some aspect of system control and is nothing more than
Boolean data—it is either on or off, true or false, there or not there.
– For example, a pressure sensor detects that pressure exceeds a
safe value and sends an alarm signal to monitoring software. The
alarm signal is an event that controls the behavior of the system.
Therefore, data (numbers, text, images, sounds, video, etc.) and
control (events) both reside within the information domain of a
problem.
 Information Domain...
• The first operational analysis principle requires an
examination of the information domain and the
creation of a data model. The information domain
contains three different views of the data and control
as each is processed by a computer program:
– information content and relationships (the data
model),
– information flow, and
– information structure.
• Each of these views should be considered.
 Information Domain...
• Information content represents the individual data
and control objects that constitute some larger
collection of information transformed by the
software.
– For example, the data object, paycheck, is a
composite of a number of important pieces of data:
• The payee's name, the net amount to be paid, the gross pay,
deductions, and so forth.
• Therefore, the content of paycheck is defined by the
attributes that are needed to create it. Similarly, the content
of a control object called system status might be defined by a
string of bits.
• Each bit represents a separate item of information that
indicates whether or not a particular device is on- or off-line.
 Information Domain...
• Information Flow This refers to the manner which
data and control objects (state information) is
``transformed'' as it moves (or ``flows'') through the
software system to be developed - and, how it is
manipulated by system functions.
– For example, in a payroll system, this might include
information about ``salary,'' ``number of hours worked,''
and data related to ``taxation'' are combined in order to
determine the ``net amount paid.''
• Information Structure This refers to the internal
organization of data and control objects.
– For example, it might include the information that a
particular (complex) collection of data should be stored
and accessed using a (randomly accessible) ``array''
structure, or that is should be organized in a hierarchical
way (using a ``tree'').
End

41