Saturday, January 28, 2017

Flow-Oriented Modeling | Data Flow Model | Control Flow Model | Control Specification | Process Specification

Flow-Oriented Modeling | Data Flow Model | Control Flow Model | Control Specification | Process Specification

Although data flow-oriented modeling is perceived as an outdated technique by some software engineers, it continues to be one of the most widely used requirements analysis notations in use today. 

Although the data flow diagram (DFD) and related diagrams and information are not a formal part of UML, they can be used to complement UML diagrams and provide additional insight into system requirements and flow.

The DFD takes an input-process-output view of a system. That is, data objects flow into the software, are transformed by processing elements, and resultant data objects flow out of the software.

Data objects are represented by labeled arrows, and transformations are represented by circles (also called bubbles).  

The DFD is presented in a hierarchical fashion.

That is, the first data flow model (sometimes called a level 0 DFD or context diagram) represents the system as a whole.

Subsequent data flow diagrams refine the context diagram, providing increasing detail with each subsequent level.

Creating a Data Flow Model

Flow-Oriented Modeling | Data Flow Model | Control Flow Model | Control Specification | Process Specification

The data flow diagram enables you to develop models of the information domain and functional domain.

 As the DFD is refined into greater levels of detail, you perform an implicit functional decomposition of the system.

Simple guidelines  the derivation of a data flow diagram:-

(1) the level 0 data flow diagram should depict the software/system as a single bubble.
(2) primary input and output should be carefully noted.
(3) refinement should begin by isolating candidate processes, data objects, and data stores to be represented at the next level.
(4) all arrows and bubbles should be labeled with meaningful names.
(5) information flow continuity must be maintained from level to level.
(6) one bubble at a time should be refined. There is a natural tendency to overcomplicate the data flow diagram.

The refinement of DFDs continues until each bubble performs a simple function.

That is, until the process represented by the bubble performs a function that would be easily implemented as a program component. called cohesion.

Control Flow Model

For some types of applications, the data model and the data flow diagram are all that is necessary to obtain meaningful insight into software requirements.

Such applications require the use of control flow modeling in addition to data flow modeling.

I have already noted that an event or control item is implemented as a Boolean value.

The following guidelines are for select potential candidate events:

·   List all sensors that are “read” by the software.
·   List all interrupt conditions.
·   List all “switches” that are actuated by an operator. 
·   List all data conditions.
·  Recalling the noun/verb parse that was applied to the processing narrative,     review all “control items” as possible control specification inputs/outputs.
·   Describe the behavior of a system by identifying its states, identify how each state is reached, and define the transitions between states.
·  Focus on possible omissions—a very common error in specifying control; for example, ask: “Is there any other way I can get to this state or exit from it?”

The Control Specification

A control specification (CSPEC) represents the behavior of the system in two different ways.

The CSPEC contains a state diagram that is a sequential specification of behavior. It can also contain a program activation table a combinatorial specification of behavior.

A somewhat different mode of behavioral representation is the process activation table. The PAT represents information contained in the state diagram in the context of processes, not states.

That is, the table indicates which processes (bubbles) in the flow model will be invoked when an event occurs.

The PAT can be used as a guide for a designer who must build an executive that controls the processes represented at this level.

The CSPEC describes the behavior of the system, but it gives us no information about the inner working of the processes that are activated as a result of this behavior.

The Process Specification

The process specification (PSPEC) is used to describe all flow model processes that appear at the final level of refinement.

The content of the process specification can include narrative text, a program design language (PDL) description of the process algorithm, mathematical equations, tables, or UML activity diagrams.

By providing a PSPEC to accompany each bubble in the flow model, you can create a “mini-spec” that serves as a guide for design of the software component that will implement the bubble. 

Monday, January 9, 2017

Requirements Modeling Strategies | Structured Analysis | Object-Oriented Analysis

Requirements Modeling Strategies | Structured Analysis

One view of requirements modeling, called structured analysis, considers data and the processes that transform the data as separate entities.

Data objects are modeled in a way that defines their attributes and relationships.

Processes that manipulate data objects are modeled in a manner that shows how they transform data as data objects flow through the system.

A second approach to analysis modeled, called object-oriented analysis, focuses on the definition of classes and the manner in which they collaborate with one another to effect customer requirements.

The question is not which is best, but rather, what combination of representations will provide stakeholders with the best model of software requirements and the most effective bridge to software design.

Validating Requirements | When I review requirements, what questions should I ask?

Validating Requirements | When I review requirements, what questions should I ask?

As each element of the requirements model is created, it is examined for inconsistency, omissions, and ambiguity.

The requirements represented by the model are prioritized by the stakeholders and grouped within requirements packages that will be implemented as software increments.

Following questions:

Is each requirement consistent with the overall objectives for the system/product?

Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage?

Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system?

Is each requirement bounded and unambiguous?

Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement?

Do any requirements conflict with other requirements?

Is each requirement achievable in the technical environment that will house the system or product?

Is each requirement testable, once implemented?

Does the requirements model properly reflect the information, function, and behavior of the system to be built?

Has the requirements model been “partitioned” in a way that exposes progressively more detailed information about the system?

• Have requirements patterns been used to simplify the requirements model? Have all patterns been properly validated? Are all patterns consistent with customer requirements?

Wednesday, November 23, 2016

The Unique Nature of Web Apps

The Unique Nature of Web Apps


In the early days of the World Wide Web (1990 to 1995), websites consisted of little more than a set of linked hypertext files that presented information using text and limited graphics.
Today, WebApps have evolved into sophisticated computing tools that not only provide stand-alone function to the end user, but also have been integrated with corporate databases and business applications due to the development of HTML, JAVA, xml etc.

Attributes of WebApps :

Network Intensiveness
Unpredictable load
Data driven
Content Sensitive
Continuous evolution

Network intensiveness.
A WebApp resides on a network and must serve the needs of a diverse community of clients.
The network may enable worldwide access and communication (i.e., the Internet) or more limited access and communication
(e.g., a corporate Intranet Network Intensiveness)

Concurrency : [ Operation at the same time]
A large number of users may access the WebApp at one time. In many cases, the patterns of usage among end users will vary greatly.

Unpredictable load :
The number of users of the WebApp may vary by orders of magnitude from day to day. One hundred users may show up on Monday; 10,000 may use the system on Thursday.

Performance :
If a WebApp user must wait too long (for access, for server side processing, for client-side formatting and display), he or she may decide to go elsewhere.

Availability :
Although expectation of 100 percent availability is unreasonable, users of popular WebApps often demand access on a 24/7/365 basis.

Data driven :
The primary function of many WebApps is to use hypermedia to present text, graphics, audio, and video content to the end user.
In addition, WebApps are commonly used to access information that exists on databases that are not an integral part of the Web-based environment (e.g., e-commerce or financial applications).

Content sensitive:
The quality and artistic nature of content remains an important
Determinant of the quality of a WebApp.

Continuous evolution:
Unlike conventional application software that evolves over a series of planned, chronologically spaced releases, Web applications evolve continuously.
It is not unusual for some WebApps (specifically, their content) to be updated on a minute-by-minute schedule or for content to be independently computed for each request.

Although immediacy—the compelling (forceful) need to get software to market quickly—is a characteristic of many application domains,
WebApps often exhibit a time-to-market that can be a matter of a few days or weeks.

Because WebApps are available via network access, it is difficult, if not impossible, to limit the population of end users who may access the application. In order to protect sensitive content and provide secure mode of data transmission, strong security measures must be implemented.

Aesthetics : [Artistic / Visual]
An undeniable part of the appeal of a WebApp is its look and feel. When an application has been designed to market or sell products or ideas, aesthetic may have as much to do with success as technical design.

Thursday, November 17, 2016

Concurrent Model | Concurrent Engineering

Concurrent Model

Concurrent Model

  • The concurrent development model, sometimes called concurrent engineering.

  • It allows a software team to represent iterative and concurrent elements of any of the process model.

  • For example, the modeling activity defined for the spiral model is accomplished by invoking one or more of the software engineering actions: prototyping, analysis, and design.

  • The activity—modeling—may be in any one of the states noted at any given time.

  • Similarly, other activities, actions, or tasks (e.g., communication or construction) can be represented in an similar manner. 
  •     All software engineering activities exist concurrently but reside in         different states.

  • For example, early in a project the communication activity (not shown in the figure) has completed its first iteration and exists in the awaiting changes state.

  • The modeling activity (which existed in the inactive state while initial communication was completed, now makes a transition into the under development state. If, however, the customer indicates that changes in requirements must be made, the modeling activity moves from the under development state into the awaiting changes state. 
  • Concurrent modeling defines a series of events that will trigger transitions from state to state for each of the software engineering activities, actions, or tasks.

Thursday, October 27, 2016

Evolutionary Process Models, stand-alone process model

Evolutionary Process Models, stand-alone process model

Evolutionary models are iterative.
They are characterized develop increasingly more complete versions of the software.

Two common evolutionary process models.
        The Spiral Model.


Customer defines a set of general objectives for software.

But does not identify detailed requirements for functions and features.

Developer may be unsure of the efficiency of an algorithm.

Prototyping paradigm may offer the best approach.

Can be used as a stand-alone process model.

Better understand what is to be built when requirements are fuzzy.

Start with communication, planned quickly, modeling, Construction, Deployment Delivery & Feedback.

Quick design focuses on GUI that visible to end users.

Quick design leads to the construction of a prototype.

Evaluated by stakeholders, who provide feedback that is used to further refine requirements.

Prototype serves as a mechanism for identifying software requirements.

Problems of prototyping

Stakeholders don’t know what appears to be a working version of the software, Unaware, Compromises in implementation working quickly.

Inappropriate operating system or programming language may be used.
Inefficient algorithm may be implemented.

Evolutionary Process Models, stand-alone process model

Incremental Process Models

Incremental Process Models

The incremental model combines of linear and parallel process flows.

the incremental model applies linear sequences deliverable “increments” of the software.

first increment is often a core product. That is, basic requirements

The plan addresses the modification of the core product to better meet the needs of the customer and the delivery of additional features and functionality.

process is repeated until the complete product is produced.

focuses on the delivery of an operational product with each increment.

useful when staffing is unavailable for a complete implementation

core product is well received, then additional staff (if required) can be added to implement the next increment.

increments can be planned to manage technical risks.
Incremental Process Models