Make your own free website on Tripod.com

Problem Statement Language/ Problem Statement Analyzer (PSL/PSA)

 

Introduction

The Problem Statement Language(PSL) and the Problem Statement Analyzer were first described in 1971. PSL was introduced in that paper as the equivalent of a blueprinting language for an information systems "factory" ad PSA as the software to support the usage. This was the first version used by mainly of the Information Design and Optimization System (ISDOS) project in University of Michigan.

 


Overview

PSL is based on the concept of the Entity-Relationship-Attribute (ERA) model. PSL allows up to four Entity-types to participate in a Relationship. Entities may have Attributes and may play roles in a relationship. However, these relationships can not have

Attributes assigned to them because these relationship-roles are not formalized yet.

PSA is the software that manages PSL statement. It can be thought as a data-based application with different categories of functionality. In simple words, PSA had simple mechanism to populate a database, to retrieve information from it and to present the results in the form of a limited number of reports.

 


Representation of Components

PSL has a set of predefined classes of

The diagram above show the summarized core architecture of PSL/PSA.

 

PSL has three levels of formality to describe a system.

Level of Formality Description
Very Formal uses only the predefined Entity-types and relationship
Semiformal adding user-defined properties
Informal free form test to entities

 

PSA has four categories of functionality.

Categories of Functionality Description
Modification It allows modification to the database, including updating and changing of its contents. The database is modified without the integrity of the underlying language.
Display It displays 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-references summaries.
Control It allows control of the PSA environment.

 


Relationship and Rules

One can think of PSL/PSA as an application built on top of a generalized Entity Relationship Attribute Management System (ERAMS) with the predefined data definition. However, many if the reports produced by PSA do not have semantic knowledge of PSL.

PSL has about 19 Entity-types and about 100 Relationship-types. These types are group in by the "aspect" of system description.

Aspects Categories
Aspect Applicable to All Principle PSL Objects. Properties and Characteristic
Project Management
Requirement Traceability
Performance Aspect Quantification and Resource Usage
Information Flow Aspects System Boundary and Input/ Output Flow
Data Derivation and Flow
Behavioral Aspects System Dynamics
System Control
Project Convenience Aspects Generic Structure
Architectural Aspects System Structure
Data Structure

PSA has different types of usage interaction. However, the major modes are stated below.

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 commands 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.

 


Strengths and Weaknesses

Strengths

 

Weaknesses

 


Appropriate and Inappropriate domains of Application and Example

Appropriate

The PSL/PSA is appropriate to use if there is discussion between the client is because as to decide which particular strategy to use in a specific situation. For example, the client may choose either a top-down or a bottom-up or an outside-in to or even an inside-out) system. The decision made allow the client organization to choose its methodology and to enable the specification of any type of information in PSL/PSA.

 

Inappropriate

PSL/PSA is inappropriate to use when there is a great amount of data retrieval from the database. This is because increase in the retrieval mechanism will increase functionality if from the ability to choose the types of Entities, to selecting the Entities with certain Attributes to choosing the Relationship. This may cause the retrieval mechanism very difficult to perform.

 


Tools related to PSL/PSA

Tools that are related to PSL/PSA method are the View Intergration System (VIS) from Meta System Ltd., and LdbD from ASTEC in Maryland. Both of these packages allow the user to take the requirements database and produce a third normal form schema to be used in the design phase. The Structured Architect Integrator (SAI) introduced by the Meta Systems Ltd. Has been at the leading edge in solving this dilemma.

The PSL/PSA tools also include Structured Analysis (SA), a PC-based drawing tools that models the concepts of Structured Analysis. It provides a set of local reports that lets the user browse through the system described by the SA. Additionally, it also can produce output that can be synthesized through SAI or can be sent directly to PSA as PSL statements.

Tools related to PSL/PSA is in the Software Engineering Environment (SEE). SEE uses PSL/PSA as it's central tool. Using this tool, the top row of the diagram shows which methodologies are supported by the tool shown in the boxes in the second row. For example, if the organization was working in the requirements in the first row and had picked a specific task in the first row, all but that specific tool would be feasible.