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

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

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.

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

Development takes less time and cost because errors can be minimized by the PSL/PSA method.
The "quality" of the documentation is improved and that the cost of the design, implementation and maintenance is reduced. This is because the analyst should be more precise and the software performs checking, and output reports that can be reviewed for errors and inconsistencies.
PSL/PSA supports support graphical interfaces that make it easier to use.

Weaknesses

PSL/PSA does not explicitly support any particular life-cycle development method. It expects the users to cast their methodology in PSL/PSA terms.
PSL/PSA often requires a major cultural shift in user organization. These shifts can go quite deep, into the very way the analysts and designers think about the system.
PSL/PSA is perceived as a being a hard to use and lack of flexibility.
PSA is restricted to specific porting in targeted hardware systems.

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.