Overview of Functional and Configuration Model in analysis for WebApps

THE FUNCTIONAL MODEL
There are two processing elements of web application. The functional model addresses the above two elements of web application:
- user observable functionality delivered by web applications to end-users.
- operations within analysis classes that implement behavior within class.

User observable functionality encompasses processing functions initiated directly by user. These functions are implemented using operations within analysis classes but from end-user point of view, the function is the visible outcome.

The operations within analysis class manipulate the attributes of the class involved as class collaborate with one another to accomplish required behavior.

THE CONFIGURATION MODEL
The web application must be thoroughly tested within every browser configuration that is specified as part of configuration model.
In some cases, configuration model is not more than a list of server and client side attributes. For complex web applications, configuration complexities have an impact on analysis and design.
Client side software provides the infrastructure that enables access to the web application from user;s location.
On server side, appropriate interfaces, communication protocols and related information should be specified if web application has to access large database or inter-operates with other applications.

How to create a behavioral model in software engineering?

While other analysis modeling elements provides a static view of the software, behavioral modeling depicts the dynamic behavior. The behavioral model uses input from scenario based, flow oriented and class based elements to represent the states of analysis classes and the system as a whole. To accomplish this, states are identified, the events that cause a class to make a transition from one state to another are defined, and the actions that occur as transition is accomplished are also identified. State diagrams and sequence diagrams are the UML notation used for behavioral modeling.

The behavioral model is an indication showing how a software responds to external event. Steps to be followed are:
- All use cases are evaluated.
- Events are identified and their relation to classes are identified.
An event occurs whenever the system and an user exchange information. An event is not the information that is exchanged but a fact that information has been exchanged.

- A sequence is created for use-case.
- A state diagram is built.
There are two different characterizations of states in behavioral modeling : state of class as system performs its function and the state of the system as seen from outside. The system has states that represent specific externally observable behavior whereas a class has states that represent its behavior as the system performs its functions.
- Behavioral model is reviewed for accuracy and consistency.

What are the different data modeling concepts?

Data model is a conceptual representation of data structures. The data structures consist of data objects, relationship between data objects and rules that govern these operations. Often, analysis modeling begins with data modeling.
The inputs of data model comes from the planning and analysis stage. There are two outputs of the data model. First is an entity relationship diagram and second is a data document. The goal of the data model is to make sure that the all data objects required by the database are completely and accurately represented.

The different concepts of data modeling are:

- Data Objects are a representation of any composite information that is processed by software. A data object can be an external entity, thing, occurrence, event, role, an organizational unit, place or a structure. The description of the data object includes data object and its attributes. A data object contains only data.

- Data Attributes name a data object, describe its characteristics and sometimes make reference to another object. One or more attributes must be identified as a key which acts as an identifier.

- Relationships indicate the manner in which data objects are connected to one another.

- Cardinality of a relationship is the actual number of related occurences for each of the two entities. It defines the maximum number of objects participating in relationship. It does not indicate whether a data object should participate in relationship or not.

- Modality of a relationship can be 0 or 1. It is 1 if an occurrence of relationship is must. It is 0 if an occurrence of relationship is optional.

What are different elements of the analysis model?

Analysis model provides description of required information, functional and behavioral domains of computer based systems. There is a set of generic elements that is common to most analysis models:

- Scenario based elements are the first part of the analysis model that is developed. They serve as input for creation of other modeling elements. In another method for scenario based modeling, if we use functions or activities that would have been defined when the requirements elicitation was being done. These functions are a part of the processing context. When you have the analysis model, you would have defined a sequence of activities and these activities in turn describe the processing within a limited context. As stated earlier in previous post, when you take the analysis model, activities can be described at multiple levels of abstraction.

- In class based elements, a usage scenario has a set of objects which are categorized into classes which is a collection of things that have similar attributes and common behavior.

- In behavioral elements, the behavior of a system effects the chosen design and implementation approach that is applied. A state is an externally observable mode of behavior. State diagrams represents behavior of system depicting states and events that cause system to change state.

- In flow oriented elements, information flows through a computer based system. System accepts input,transform them using functions and produces output.

How is data designed at architectural and component level?

Data Design at Architectural Level

Data design translates data objects defined during analysis model into data structures at the software component level and, when necessary,a database architecture at the application level.
There are small and large businesses that contains lot of data. There are dozens of databases that serve many applications comprising of lots of data. The aim is to extract useful information from data environment especially when the information desired is cross functional.
Techniques like data mining is used to extract useful information from raw data. However, data mining becomes difficult because f some factors:
- Existence of multiple databases.
- Different structures.
- Degree of detail contained with databases.Alternative solution is concept of data warehousing which adds an additional layer to data architecture. Data warehouse encompasses all data used by a business. A data warehouse is a large, independent database that serve the set of applications required by a business. Data warehouse is a separate data environment.

Data Design at Component Level

It focuses on representation of data structures that are directly accessed by one or more software components. Set of principles applicable to data design are:
- Systematic analysis principles applied to function and behavior should also be applied to data.
- All data structures and operations to be performed on each should be identified.
- The content of each data object should be defined through a mechanism that should be established.
- Low level data design decisions should be deferred until late in design process.
- A library of data structures and operations that are applied to them should be developed.
- The representation of data structure should only be known to those modules that can directly use the data contained within the structure.
- Software design and programming language should support the specification and realization of abstract data types.

Designing Class based Components - Component Level Design Guidelines

As component level design proceeds, there are some guidelines other than basic design guidelines. These guidelines are applied to components and their interfaces, their dependencies and inheritance.

COMPONENTS
- Naming conventions should be established for components.
- These are specified as part of architectural model and then refined and elaborated as part of component level design.
- Architectural component names should be drawn from the problem domain.
- It should have meaning to all stakeholders.

INTERFACES
- Provides information about communication and collaboration.
- Lollipop approach to represent interface should be used in combination with UML box and dashed arrow.
- Interface should flow from left side of the component box for consistency.
- Only relevant interfaces to component should be shown.

DEPENDENCIES AND INHERITANCE
- Model dependencies from left to right.
- Model inheritance from bottom to top.
- Component interdependencies should be represented via interfaces.

Component Level Design - Important Views that describes what a component is?

An Object Oriented View of Component

- From an object oriented viewpoint, a component is a set of collaborating classes.
- Each class within a component consists of attributes and operations relevant.
- Interfaces enabling the classes to communicate with other design classes are defined.
- Designer accomplishes this from analysis model and elaborates analysis classes and infrastructure classes.
- Analysis and design modeling are both iterative actions. Elaborating original analysis class may require additional analysis step which are then followed with design analysis steps to represent elaborated design class.
- Elaboration activity is applied to every component.
- After this, elaboration is applied to each attribute, operation, and interface.
- Data structures are specified.
- Algorithms for implementing each logic is designed.

The Conventional View

- A component is functional element of a program, also called module.
- It incorporates processing logic, internal data structures, interface that enables the component to be invoked and data to be passed to it.
- It resides within software architecture.
- It serves one of the roles control component, problem domain component or an infrastructure component.
- Conventional components are also derived from analysis classes.
- Data flow oriented element of analysis model is the basis for derivation.
- Each module is elaborated.
- Module interface is defined.
- Data structures are defined.
- Algorithm is designed using stepwise refinement approach.
- Design elaboration continues until sufficient detail is provided.

Process Related View

- The above two approaches assume that component is designed from scratch.
- Emphasize is on building systems that make use of existing software.
- As software architecture is developed, components or design patterns are chosen from catalog and used to populate the architecture.

User Interface Analysis and Design - The Process

The analysis and design process for user interfaces is iterative that is represented using a spiral model. User interface analysis and design process consists of four framework activities:
- User, task and environment analysis and modeling.
- Interface design.
- Interface construction.
- Interface validation.
The construction activity involves prototyping. Interface analysis focuses on the profile of users who will interact with system. Different user categories are defined. Requirements are obtained for each user category.

After the requirements are defined, detailed task analysis is conducted. Tasks performed by users are identified, described, and elaborated. The analysis of user environment focuses on physical work environment.Things that one should know about the environment as the user interface design begins are:
- Physical location of interface.
- Will the user sitting, standing or performing some other tasks unrelated to interface?
- Does the interface hardware accommodate space, light, or noise constraints?
- Any human factors that are driven by environmental factors?

- Analysis model is created using the information gathered from analysis activity.
- Design activity starts using analysis model as a basis.
- Interface design defines a set of interface objects and actions.
- Construction activity begins with creation of prototype that enables usage scenarios to be evaluated.
- Validation focuses on interface ability to implement every user task correctly, degree to which interface is easy to use and learn and users' acceptance of the interface.

Analysis for Web Applications - The Functional Model and The Configuration Model

The functional model describes two elements of web application :
- User Observable Functions: Delivered by web application to end users. It encompasses any processing functions that are initiated directly by the user. These functions may be implemented using operations within analysis classes but from the point of view of an end-user, the function is the visible outcome.
- Class Operations: Implement behaviors associated with the class. These operations manipulate class attributes and are involved as classes collaborate with one another to accomplish some required behavior.
The UML activity diagram can be used to represent processing details.

The Configuration Model describes the environment that the web application will require on both the server and client side of the system. Although it is very important to consider all configurations that are likely to be used, a web application must be engineered to serve its end-users. Web application resides on a server that provides access via Internet, Intranet or an Extra-net. Server hardware and operating system must be specified. Also, interoperability considerations on the server side should be considered.

Client side software provides an infrastructure that enables access to web application from user's location. Web application content and functionality is delivered by browser software. Each browser has its own peculiarities.

Overview of The Content Model for Web Applications

The content model is derived from an examination of use cases developed for the web application. This model contains structural elements that provides a view of content requirements for a web application. Structural elements include content objects like text, images, audio, video and photographs.It also contains analysis classes which cover attributes that describe it, operations that effect the behavior and collaborations.

A content object is any item of cohesive information that is to be presented to an end-user. These content objects are extracted from use cases. Content can be developed before the web application implementation, while the web application is being built or long after web application is operational.
The web engineer meets the person who has designed the use case and obtain a more detailed understanding of what descriptive and pricing information means. The descriptive information includes a paragraph of general description of component, photograph of component, a multi-paragraph technical description of component, a schematic diagram of component and a thumbnail video that shows how to install the component.

Content objects with a brief description of each object is more than enough to define the requirements for content that must be designed and implemented. In some cases, a data tree is used to represent a hierarchy of content objects. The content model may contain entity relationship diagrams that describes the relationship among content objects.

Analysis Model and analysis activities for Web Applications

The analysis model of web application is driven by information contained within the use cases that have been developed for the application. Analysis modeling focuses on four fundamental aspects - content, interaction, function, and configuration. Content that is presented by the web application is identified and functions to be performed are extracted from use case descriptions.

TYPES OF ANALYSIS ACTIVITY OCCURRING DURING MODELLING OF A WEB APPLICATION

- Content analysis: It identifies the content across the full range provided by the web application. The content includes text, graphics, images, audio and video.
- Interaction analysis: The user interaction with the web application is defined in the interaction analysis.
- Functional analysis: There are operations and some other processing functions that are applied on the web application. These operations and processing functions are defined in functional analysis. These functions are independent of content but necessary for the end user.
- Configuration analysis: The environment and infrastructure is described in which the web application resides.

All the information that is obtained from these four steps is reviewed, modified as required and then organized into a model which contains structural elements that identifies analysis classes and content objects and dynamic elements that describes all the structural elements interact with one another and with end users.

Overview of analysis for Web Applications

Web application analysis focuses on the information or content that is to be presented, the functions that are to be performed for the end user and behaviors that a web application exhibits as it presents content and performs functions.

Web application analysis model is comprised of a set of UML diagrams and text that describe content, interaction, function and configuration. Analysis of web applications is done when the following conditions are met:
- Web application to be built is large and complex.
- Number of stakeholders is large.
- Number of web engineers and other contributors is large.
- Web application's goals and objectives will effect the business bottom line.
- Success of web application will have strong bearing on the success of business.

Requirement analysis consists of formulation, requirement gathering and analysis modeling. In formulation, goals, objectives and categories of users are defined. In requirement gathering, communication between web engineering team and web application stakeholders intensifies.
Building a user hierarchy provides with a snapshot of the user population and a cross-check to ensure that the needs of every user have been addressed.

A use case diagram is created for each user category. Use cases are organized into functional packages and each package is assessed to ensure that it is comprehensible, cohesive, loosely coupled and hierarchically shallow.

Requirement analysis and modelling are iterative activities, new use cases are defined and added to packages, existing use cases will be refined and that specific use cases might be reallocated to different packages.