ARCHITECTURAL DESIGN
Data Flow Diagram (DFD)
Design Methodology Classes belong to
Notation
 |
Process Transform of
incoming data flow(s) to outgoing flow(s)
|
 |
Data Flow Movement of data
in the system
|
 |
Data Store Data
repositories for data that are not moving. It may be as
simple as a buffer or a queue or as sophisticated as a
relational database
|
 |
External Entity Sources of destinations outside the
specified system boundary
|
Expansion
- Each activity of the system can be broken down into
sub-activities to demonstrate the higher-level activity.
The "context-level" DFD shows the application
as a single box with interfaces to the external sources
and interfaces to the users of the application's data.
The next-level DFD is a decomposition of the single box
from the context-level diagram.
Abstraction
- DFD may be used for any level of data abstraction.
Modularization
- Reuse of modules without modifying them internally is
possible with DFD. The arrow in a DFD means there is a
flow of data but not call a statement.
Organization
- DFD may look like a precedence diagram, a call-hierarchy
chart, or even a flow chart. However, the significant
difference is its arrows. The direction of the arrows
describe what information is being passed. DFD show in
the pictorial way so that the viewer can see what is
going on in the system exactly.
Encapsulation
- The data object only encapsulates the data.
Applicability and Appropriateness with Project developed
- DFD is highly appropriate with my project. My project was
a database type software which need data processes, data
store and data view. With DFD, I can design the data flow
from the database and how data to be stored into the
database.
References
Hierarchical Object-Oriented Design
(HOOD)
Design Methodology Classes belong to
- Abstract machines and object-oriented design
Notation
- Graphical notation allows the expression of an
abstraction of a solution in a clear, easy-to-understand,
high-level notation
- The textual notations allow the formal expression and the
refining of the object's characteristics and properties
by means of an Object Description Skeleton (ODS). This
latter structures the descriptions into separate fields
that support appropriate control and program description
notations (Ada lke PDL). Finally, the descriptions may be
fully translated into a target language (Ada, C, C++,
Fortran).
Expansion
- A system-to-design hierarchy or Hood Design Tree (HDT)
associated to the STD, which is an emphasized part of the
object space and which defines orthogonally client-server
and composition relationships between objects.
Abstraction
- Branches of HDT represent parent objects decomposed into
child objects, and where leaves are terminal objects
which cannot be further decomposed.
Modularization
- The object is the unit of modularity.
Organization
- The Object Control Structure (OBCS), which is unique for
an object, controls the activation and triggering of
constrained operation, whereas non-constrained operations
execute directly under the client requesting process. The
OBCS thus describes and enforces the object dynamical
behavior.
- The Operation Control Structures (OPCS, one by provided
service/operation), which describes how a sequential
process executes within an operation.
Encapsulation
- Object encapsulates state, as well as a set of services
that it requires from other objects. A service is an
abstraction of an operaton and/or access to an
attribute/component of the state of an object.
Applicability and Appropriateness with Project developed
- HOOD is not applicable with my project because the
database is standalone and the fields of the database are
the attributes of the object. The project cannot be
designed in a hierarchical way where it only has one
object.
References
- Encyclopedia of Software Engineering, Volume 1, Volume 2
by John J. Marciniak
DETAILED DESIGN
Hierarchy Input-Process Output (HIPO)
Design Methodology Classes belong to
Notation
- The notations are included in the Input Process Output
(IPO) diagram. The IPO has 3 panels. The first listed the
module inputs in the left panel, the center is the
description of the processing logic in structured English
or as a flowchart, and the list of module outputs in the
right panel. In the center the, there is the description
of the processing logic containing English or as a
flowchart.
Expansion
- HIPO is designed in top-down manner. The HIPO uses the
concept of decomposition. The HIPO chart expands more in
detail when high of the chart is getting bigger.
Abstraction
- HIPO work together to fully represent a system at all
levels of abstraction until there is sufficient detail
for implementation using a formal programming language.
Modularization
Organization
- The process take three different levels of abstraction
occurs in the system level and is meant to model the
major subsystems. The system level can contain multiple
levels. The next level of refinement is the program
level. In this level, HIPO provides a functional
description of the observable behavior. The final level
is the module level. In this level, the goal of the
functional descriptions is to contain sufficient detail
to be directly implemented with a formal language.
Encapsulation
- The right hand side encapsulate the output of the IPO
chart.
Applicability and Appropriateness with Project developed
- HIPO is applicable to my project because HIPO is
efficient for batch processing. It work well for batch
processing where the input data is collected in streams
and processed in sequence by one or more jobs. In my
project, I need a database to store clients data and it
will be used in other functions like announcement, view
database function and edit database.
References
Problem Statement Language/Problem
Statement Analyzer (PSL/PSA)
Design Methodology Classes belong to
Notation
- PSL has a set of predefined classes of
- Entities (e.g. Process, Input, Element, Event)
- Relationship (e.g. Employs, Updates, Triggers)
- Attributes (e.g. Tracekey)
- A set of rules (the construct of the language) which
permit only prescribed combinations
Expansion
- Two added functionality that of designing a database from
the specifications of requirements. One, Development of
View Integration System (VISTM) from Meta
System, Ltd., and LdbDTM from ASTEC in
Maryland. Two, The Structured Architect Integrator (SAITM),
introduced by Meta Sustem Ltd. can play a role of the
arbiter between varous users and support the data
administrator responsible for coordinating the
development of the PSA database.
Abstraction
- Data abstraction is provided by PSL/PSA by its graphical
interfaces.
Modularization
PSA has four categories of functionality
| Categories of Functionality |
Descriptions |
| Modification |
It allow modification to the
database, including updating and changing of its
contents. The database is modified without the integrity
of the underlying language. |
| Display |
It display the information
in the database as predesigned reports |
| Analysis |
This
analysis focuses on in errors of omission and on the
production of numeric and cross-reference summaries. |
| Control |
It allows control of the PSA
environment. |
Organization
The major modes of interaction are
| Types of mode |
Descriptions |
| Interactive |
PSA commands type at the
terminal and PSA prompts, error message, and reports
received on the terminal. |
| Batch |
PSA executing commands from
a file containing a sequence of comands and without
prompting; writing error messages and reports to a file
or designated printer. |
| Monitored |
Similar to batch mode but
echoing the commands being executed and displaying
messages on the terminal. |
Encapsulation
- PSL encapsulates the concept of the
Entity-Relationship-Attribute (ERA) model. PSL allows up
to four Entity-types to participate in a Relationship.
Applicability and Appropriateness with Project developed
- PSL/PSA is appropriate with my project because the client
can specify their problem statement and I can analyze the
problem statement. Also, It is important to know the
relationship between entities and attributes.
References