Problem Statement Language/ Problem Statement Analyzer (PSL/PSA)
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.
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.
|Aspect Applicable to All Principle PSL Objects.||Properties and
|Performance Aspect||Quantification and Resource Usage|
|Information Flow Aspects||System Boundary and Input/
Data Derivation and Flow
|Behavioral Aspects||System Dynamics
|Project Convenience Aspects||Generic Structure|
|Architectural Aspects||System 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
Appropriate and Inappropriate domains of Application and Example
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.
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.