Web-user interface

ABSTRACT

The development of software using services is nothing but composing and configuring services to create new and composite services. These services may be integrated using web-user interface to create a web-application or may be used in some other applications as components. These services may be specially developed for the application, or may be services from an external source. Many companies are now concentrating on converting the applications within the enterprise into a service-oriented system. This in turn will open up the chances of reuse within the company. Next step would be developing inter-organizational applications. For all these stages to be successful, it is necessary to have a well-planned analysis, design and implementation. The article below gives a detailed description of requirements and design modeling for systems and services.

INTRODUCTION

In recent years computers have developed very rapidly from simple processing machines to sophisticated communication systems employing multiple media. Computers are increasingly used for all kinds of man-machine and interpersonal communication and co-operation. Many of these applications involve multiple communicating entities as well as multimedia. However, in general no sufficient support for multimedia group communication is yet available. The study is based on the examination of existing systems and services and system scenarios.

REQUIREMENTS

The first step in adopting any information technology consist of deciding what purpose the system will address and what functionality the target institution requires. The complexity of a software system is determined partly by its functionality i.e. what the system does and partly by global requirements on its developmental or operational costs, performance, maintainability, portability. Requirements describe the needs of the customers. It is a single document that explains the services that is expected to be performed by a product.

1. System Requirements

The requirements for a system explain the services expected by the system to be performed and operational constraints on the system. Computer-based systems must implement functional and non-functional stakeholder requirements. Software architectures develop these requirements into an overall structure of the future system. It is very vital to create a relationship between requirements and architectures. The steps involved in identifying requirements for a system are:

  1. Feasibility study.
  2. Requirement elicitation
  3. Requirement evaluation
  4. Grouping and clustering of requirements.

System requirements are classified as functional and non-functional:

1.1Functional System Requirements

Functional requirements capture the intended behavior of the system. These are the services that are expected to be provided by the system, how the system should react, when a particular input is given and how a system should behave in a particular situation.

Functional Requirements should include the details specified below:

  • Descriptions of data to be entered into the system
  • Descriptions of operations performed by each screen
  • Descriptions of system reports or other outputs
  • The person authorized to enter the data into the system.
  • Whether the system meets applicable regulatory requirements

Some Examples of functional requirements are:

Interface requirements

  • Text field accepts numeric data entry
  • Text field only accepts dates before the current date
  • Screen can print on-screen data to the printer

Business Requirements

  • Data must be entered before a request can approved
  • Clicking the Approve Button moves the request to the Approval Workflow

1.2 Non-functional requirements

These are the constraints on the services offered by the system. They include constraints on the development, standard, performance etc. If the non-functional requirements are not given the necessary attention, then it makes it harder to prioritize and make trade-offs between the quality of the product, the cost to develop and enhance it, and the time-to-market of current and future releases. Without quality targets to guide the architects and engineers, design choices are arbitrary, and it is hard to assess the system during architecture and design reviews and system test.

Non-functional requirements arise through user needs, budget constraints, organizational policies, interoperability with other software/ hardware systems, external factors such as safety regulations or privacy legislations. The figure below illustrates a classification of non-functional requirements.

Here are some categories and "trigger questions" that may help in understanding the non-functional requirements:

  • Performance Characteristics
    • Are there any speed, throughput, or response time constraints on the system?
    • Are there size or capacity constraints on the data to be processed by the system?
  • Error Handling and Extreme Conditions
    • How should the system respond to input errors?
    • How should the system respond to extreme conditions?
  • System Interfacing
    • Is input coming from systems outside the proposed system?
    • Is output going to systems outside the proposed system?
    • Are there restrictions on the format or medium that must be used for input or output?
  • Quality Issues
    • What are the requirements for reliability?
    • Must the system trap faults?
    • Is there a maximum acceptable time for restarting the system after a failure?
    • What is the acceptable system downtime per 24-hour period?
    • Is it important that the system be portable (able to move to different hardware or operating system environments)?
  • System Modifications
    • What parts of the system are likely candidates for later modification?
    • What sorts of modifications are expected?
  • Physical Environment
    • Where will the target equipment operate?
    • Will the target equipment be in one or several locations?
    • Will the environmental conditions in any way be out of the ordinary (for example, unusual temperatures, vibration, and magnetic fields)?
  • Security Issues
    • Must access to any data or the system itself be controlled?
    • Is physical security an issue?
  • Resources and Management Issues
    • How often will the system be backed up?
    • Who will be responsible for the back up?
    • Who is responsible for system installation?
    • Who will be responsible for system maintenance?

Kinds of Constraint

Given below is a partial list of constraints along with the domain they are applicable for:

Constraints on the end product:

  • Reliability and availability constraints
    • Hours of online operation
    • Tolerable frequency and duration of outages.
    • Tolerable frequency and volume of lost data.
  • Performance constraints:
    • Response times for given transaction types
    • Number of concurrent users
    • Transaction entry rates
    • Database size
  • Environment constraints
    • Operating system
    • Database management system
    • Minimum hardware configuration
    • Use of (specified) application software product(s)
    • Look-and-feel of external user interface
  • Constraints on the development:
    • Use of programming languages
    • Use of C.A.S.E. tools
    • Use of outside contractors
    • Testing environment

To summarize, there are some additional challenges with non-functional requirements which needs to be given special attention in the development process are

  1. Non-functional requirements being subjective, it is difficult to measure/ quantify them.
  2. Non-functional requirements might relate to quantities, which cannot be realized at the requirements stage.
  3. Non-functional requirements often contradict each other.

2.Service Requirements

Services being reusable, distributed, discoverable, autonomous, and getting dynamically composed to new loosely coupled application calls for new approaches ,it is necessary to deal with functional and in particular with non-functional requirements.

2.1Functional requirements

Service functional requirements should include all the details a service must do. A use-case is given below to explain the details to be included in a functional requirements document.

Use-Case-Catalog service

A large company, selling computers equipments are giving special offers to some customers. The company wants to automate the catalog service, so that the customers can select the equipment they need. The orders cannot be placed directly, through an interface, but can be made through web-based system. Every company will have their own ordering process, procedures and rates.

The functional requirements for the catalog service can include the following details:

  1. The service provider name.
  2. The service user names should also be included.
  3. The communication channel and the interfaces required.
  4. It should include details about all the functionalities provided by the catalog service system. The details can be as follows:
    • If the catalog users are facing any difficulty in using the catalog service, then there is a problem reporting and tracking functionality provided.
    • User can also post their reviews and comments using the online catalog web service.
    • Every company will have their own catalog interface, where the employees can order equipments for the agreed prices.
    • The catalog can be downloaded by the customer employee, to work on it offline.
    • Price and specification comparison can be done for certain number of items (say 6).
    • Searching and browsing facilities are provided for the catalog users.
    • Predicted delivery date of the ordered item can be viewed using the catalog service.
    • Online purchasing of the product is allowed to be done.
    • The products, if not available can be put on hold on behalf of the customers and ship the same to the customers as soon as available.
  5. Descriptions of data to be entered into the system
  6. Descriptions of operations performed by each screen
  7. Descriptions of system reports or other outputs
  8. The person authorized to enter the data into the system.
  9. Whether the system meets applicable regulatory requirements.

The screenshot below explains the functional description of catalog service operation.

2.2Non-functional requirements

Non-functional requirements are referred as, those requirements which are not concerned with the functionality of the system. These are the constraints on the services offered by the system. Non-functional requirements not only affect the product under development, but also development process as a whole. In service oriented context, non-functional requirements are referred as "Quality of Service".

The main difference between non-functional requirements of systems and services is a high level of difficulty in handling highly distributed nature of service-oriented applications. Some characteristics that impose additional challenges on developing service oriented environment are: Varying service development, complex and varying cost structure, service shared across stakeholders. These characteristics result in a large number of deployment variations. Also, during service development, resource loading and sharing have to be taken into account too.

The service development process is divided into several stages. There are some specific considerations, which has to be made in the phase of service design and decomposition.

  1. Different stake holders use the same service in different context depending on their varying non-functional needs.
  2. Development is usually different from services. So, while designing non-functional requirements, the run-time errors cannot be considered.
  3. When services from external service providers are included, there will be lack of influence of non-functional requirements.

There are some more complications when non-functional services requirements have to be decided:

  1. When a composite service (combination of many services) has to be used, then non-functional requirements are affected because of dependencies among different services.
  2. The utilization rates of services by different stakeholders are unpredictable and cannot be planned in advance. This in turn will affect the non-functional requirements.

The figure above includes the service-oriented taxonomy for non-functional requirements:

  1. Process requirements
  2. External requirements
  3. Service requirements.

1. Process Requirements

These are the requirements based on development process of services. This includes design, discover, composition and runtime.

2. External Requirements

External requirements are those requirements which are external to the service. This can be considered as summarization of non-functional requirement. This proves that, these requirements should be given extreme importance at the initial stages of the process, or else it might cause problems at the later stage of the project.

These requirements are the actual non-functional requirements. These requirements are directly placed on the individual services or the system which service-oriented. It is necessary to derive these requirements directly from the user needs, unlike the earlier two requirements which are domain and environment based.

3. Design Modeling System and Services:

Structure of any software system and analysis model of any software system are usually used to build any design model to demonstrate how actually the related software system will be implemented at the end. So basically design modeling of any system is totally dependent on analysis and architectural requirements of the system. Design Model contains application component based on different functionalities in system and it also decides their place and use within overall architecture.

Design Model of any system also contains different design elements of the system like design classes, subclasses, interfaces. Each package can contain any number of sub packages which can be divided further into designed elements.

What is System Design Model?

The system design model describes what exactly to be done to the services of that particular system model to support the interactions as well as functionalities.

  • It helps in developing software systems to give users access to data.
  • Interface to support interactions between modules in the system.
  • And provides a way to integrate services.

Standards:

  • The interface part states what access is provided to users. Users are connected to the access provided for them.
  • The repositories part defines the data stored by the service.
  • The programs part defines the systems that must be provided to support the interfaces.
  • Links between the services state how integration is achieved.

In the example two services are proposed.

  • The office system is used by the assistant to prepare design documents.
  • The WWW is used to display the documents and collect comments and opinions.
  • Amended documents are published on the WWW.
  • Collected comments are transferred to the office system.

4. System Modeling

Basically System Modeling means abstract description of different systems whose requirements are being analyzed. It helps analyst to understand the whole system with different perceptions and the generated models are used to communicate with others. Different Models explains the same system with different perceptions and various views for the same system are always available.

  • External perspective is used in showing the system's environment.
  • Behavioral perspective is used in showing and identifying different behaviors of the system.
  • Structural perspective is used in showing structure and architecture of the system.

Structured Methods use system models as an inherent part of the method. These methods describe set of possible models for the system along with the process to derive this model which also includes rules for that system.

4.1. Different Types of Models:

Context Models:

These Models are used to define the boundaries of the system according to requirements. Social as well as organization concerns are also kept into mind when positioning such system boundaries.

Architectural Models:

Always in large software application, large system is divided into smaller subsystems to make it easier to build and develop. So in case of such applications, Architectural Models are used to show relationship of a large system with all divided subsystems.

Processing Models:

These models are used to identify overall main process of a system and other processes which are supported by the whole system. For modeling such processes, data flow diagrams are used here too to show the whole process along with the data flow from one process to another.

Behavioral Models:

These models are used to show actual behavior of the whole system. There are generally 2 kinds of behavioral models.

  1. Data Processing Models
  2. State Diagrams

Ø Data Processing Models:

Data Flow Diagrams are used to show actual data processing in any software system. These diagrams are used to find out processing of data in software system and thus by using these models we would be able to find end to end data after every subsystem.

Ø State Diagrams:

These diagrams are used to model the actual behaviour of the system according to internal as well as external events which affect the system. Such diagrams are often used in case of real time systems. These diagrams model the system in regards to nodes and stats of the system. When any event occurs in a system, it will move from one state to another.

Object Models:

These models are used to describe the whole system in terms of object classes. System is divided into classes having objects and functions (operations based on events) which can be further divided into 3 different kind of models.

  1. Inheritance Models
  2. Interaction Models
  3. Aggregation Models

So basically system modeling is the way to identify how actually the system should be working. And to examine how various subsystems work together to product a particular output, we can use above mentioned modeling techniques. These subsystems which make up a whole system, generally has resources processed in various ways to produce the desired outcome.

4.2. When to use System Modeling:

By using modeling for different software systems, it helps in making the whole system easier to understand all the relationships exist among different processes and the impact of one process on another and vice versa. System modeling is useful and valuable when overall picture is needed for any system. In software industry, when team related to any project doesn't know from where to start for the project allocated to them, system modeling can help them in indentifying problems or in analyzing any problem by showing different sides of the system and the relationships among them.

5. Service Modeling:

Service oriented modeling is used to combine business and systems together. It can be helpful in designing and specifying business which is based on services within service oriented architecture. Service oriented modeling technique typically involves a modeling language which is employed by both the business known as "Problem Domain Organization" and Information Technology Department known as "Solution Domain Organization".

This modeling methodology typically creates models that generate comprehensive view of the analysis, design and architecture including all software subsystems in an organization. Every individual of a team needs to understand this comprehensive view. And so in service oriented modeling typically refers software subsystems as "assets" and these "assets" are collectively known as "services".

There are various types of approaches for Service Oriented Modeling:

  • Service Oriented Analysis and Design (SOMA)
  • Service Oriented Modeling Framework (SOMF)

5.1. Service Oriented Modeling and Architecture (SOMA):-

SOMA was introduced by IBM in 2004 which is one of the first methodologies for SOA related methodology. It refers to domain of service modeling necessary to design and create SOA. SOMA implements service oriented analysis and design using identification, specification and realization of services, subsystems that understands those services known as service components and different flows (processes) are used to combine services.

SOMA involves an analysis and design method that extends traditional object oriented and component based methodologies and design methods to include concerns related to SOA. It is majorly divided into 3 parts.

  1. Identification
  2. Specification
  3. Realization

All of the above parts generally consist of 3 main elements of SOA.

  1. Services
  2. Components
  3. Realize those services

5.1.1. SOMA Life Cycle Modeling Activities:

It consists of above mentioned phases like identification, specification, realization, implementation, deployment and management in which the fundamental and basic building blocks are identification followed by specification, realization and then implementation in each phase. They all are related to services, components and flows which in turn related to information, policy and contracts.

5.2. Service- Oriented modeling Framework:

It was developed by Michael Bell as a Service Oriented Modeling Language for software development that employs to provide strategic solutions to enterprise problems. This modeling language can be used to design and develop any application, business and technological environment, either local or distributed.

5.2.1. Service-oriented modeling framework (SOMF)

The service oriented modeling framework (SOMF) is a service oriented development life cycle methodology. It has a number of modeling practices and disciplines that contribute to a successful service oriented life cycle management and modeling. SOMF has 4 sections of modeling framework that identify the general directions and related units of work that make up a service oriented modeling strategy : practices, environments, disciplines and artifacts. There should be service oriented development life cycle strategy which helps in setting boundaries, time frame, responsibilities and accountabilities and achievable project outcomes.

5.2.2. SOMF Life Cycle Modeling Activities

SOMF usually has process of services for development. This approach enables business and information technology to concentrate on outputs that related to a specific service oriented life cycle stage. It introduces 5 major life cycle modeling activities that drive a service evolution during design time and run time. At the design time, service originates as a conceptual service, then it transforms into an analysis service, after that it transforms into a contractual and logical service known as design service and finally at the end it is established as a solution service.

  • Service-oriented discovery & analysis modeling:
  • Discover and analyze services for granularity, reusability, interoperability, loose-coupling, and identify consolidation opportunities.

  • Service-oriented business integration modeling:
  • Identify service integration and alignment opportunities with business domains' processes (organizations, products, geographical locations)

  • Service-oriented logical design modeling:
  • Establish service relationships and message exchange paths. Address service visibility. Craft service logical compositions. Model service transactions

  • Service-oriented conceptual architecture modeling:
  • Establish an SOA architectural direction. Depict an SOA technological environment. Craft an SOA technological stack. Identify business ownership.

  • Service-oriented logical architecture modeling:
  • Integrate SOA software assets. Establish SOA logical environment dependencies. Foster service reuse, loose coupling and consolidation.

5.2.3. SOMF Modeling Styles:

SOMF provides four major software modeling styles which can be used throughout a service life cycle that includes conceptualization, discovery, analysis, business integration, logical design and logical architecture. Modeling styles of SOMF are as below:

  1. Circular
  2. Hierarchical
  3. Network
  4. Star

These modeling styles can help a software modeler with following modeling sides:

  • It will identify relationships between services both contextual as well as technological.
  • It decides message routes between customers and services.
  • According to relationships between services it will provide effective service orchestration and choreography methods. It also creates powerful service transaction from one service to another and generates behavioral patterns depending on the same.

Description of SOMF Modeling Styles:

Above mentioned figures are four different styles of SOMF. Each modeling pattern detects various approaches and strategies that will be used when modeling a service ecosystem.

Circular Modeling Style:

This style of modeling enables message exchange in a circular fashion instead of allowing controller to carry out distribution of messages. The circular style also offers particular method to affiliate the services.

Hierarchical Modeling Style:

This modeling style has a relationship pattern between services for establishing transactions and message exchange routes between consumers and services. It generates parent and child associations between each related services.

Network Modeling Style:

Using this modeling style we can generate "many to many" relationship between services, their peer services and consumers. So network modeling style is used on distributed environments and interoperable computing networks.

Star Modeling Style:

This pattern arranges services in a star formation, in which the central service passes messages to its sub services. The star modeling style is also used in "multicasting" or "publish and subscribe" instances, where different styles of messages involved like "fire and forget" and "solicitation".

5.2.4. SOMF Modeling Assets:

SOMF introduces 3 major service formations. These formations are software entities that generally exist in computing environments.

Atomic Service

Atomic service is an indivisible software component that is too granular and executes fewer business or technical functionalities. An atomic formation is also a piece of software that typically is not subject to decomposition analysis activities and its business or technological functionality does not justify breakdown to smaller components. Examples: customer address service and checking account balance service.

Composite Service

Composite service is a composite service structure aggregates smaller and fine-grained services. This hierarchical service formation is characteristically known as coarse-grained entity that encompasses more businesses or technical processes. A composite service may aggregate atomic or other composite services. Examples: customer checking service that aggregates smaller checking account and savings account services. It is an application that is composed of sub-systems, an ESB that is composed of routing, orchestration, and data transformation components.

Service Cluster

This is a collection of distributed and related services that are gathered because of their mutual business or technological commonalities. A service cluster both affiliates services and combines their offerings to solve a business problem. A cluster structure can aggregate atomic as well as composite formations. Examples: A Mutual Funds service cluster that is composed of related and distributed mutual funds services. For example, a Customer Support service cluster that offers automated bill payments, online account statements, and money transfer capabilities.

5.2.5. SOMF Modeling Notation

Each SOMF cycle has a specialized notation. To assist model the analysis and identification of services, service oriented discovery and analysis is used. Moreover, during the design phase the SOMF design, they use symbols to help model a logical design, design composition and a service transactional model.

For service identification and inspection, there are two types of modeling tasks.

  • Contextual Analysis & Modeling
  • Structural Analysis & Modeling

These activities are performed to produce a service-oriented analysis proposition.

Here is a short description for these symbols:

  • Generalized: Increases service abstraction level and broadens service deliverables.
  • Specified: Decreases service abstraction level and limits service deliverables.
  • Expanded: Expands service operations in a distributed environment.
  • Contracted: Trims service operations in a distributed environment.

Here is a short description for these symbols:

  • Aggregated: Depicts containment of services
  • Unified: Joins services by creating a new service
  • Compounded: Groups services that offer collaborative solution
  • Decomposed: Detaches a child service from its containing parent
  • Subtracted: Retires a service
  • Transformed: Converts a service structure to another formation (i.e from Atomic to Composite, etc,)
  • Intersected: Intersects two or more service clusters
  • Overlapped: Identifies the overlapping region between two or more service clusters
  • Excluded: Isolates the overlapping region of a two ore more intersected service clusters
  • Clipped: Isolates a service from a distributed environment
  • Coupled: Structurally couples two autonomous services in a distributed environment
  • Decoupled: Structurally separates two autonomous services in a distributed environment
  • Cloned: Duplicates an instance of a service by creating a new and identical service
  • De-cloned: Separates cloned services
  • Bound: Identifies a contract between two services
  • Unbound: Identifies a contract cancellation between two services
  • Operation Numbering: Illustrates the sequence of analysis and modeling operations
  • Comment: A place to put comments next to each asset or operation

6. CONCLUSION

Requirements engineering includes what a system and a service should do, the essential emergent properties and the constraints on the systems and services. So requirements engineering act as a connection medium between user, customers and developers. System requirement engineering can be classified into functional and non-functional. Similarly, service requirement engineering can be classified into functional service requirement and non-functional requirement. It can be concluded that gathering requirements for services is much more challenging as compared to system requirements. Modeling for the services and system helps in presenting two different principles like business as well as technological views. So design modeling of any system and services is basically dependent on analytical, conceptual and architectural views of that particular system and service. And thus by using modeling, we would get an idea at the very beginning, how actually the software would be developed at the end. So, requirements and modeling of any system and service should be the very first step to the development of any large software application and when software is to be used as a service.

7. REFERENCES

  • http://en.wikipedia.org/wiki/Service-oriented_modeling
  • http://www.oasis-open.org/committees/download.php/19361/soa-rm-cs.pdf
  • http://www.qaproject.org/methods/ressysmod.html
  • http://www.columbus.gr/documents/public/WPHS/Columbus_DHS3_0.2_Cover.pdf
  • http://books.google.com/books?id=NAyhSRjPWEIC&dq=Modeling+for+system+and+services&printsec=frontcover&source=in&hl=en&ei=JvvxS-rPFZOyswPSwNX8Cw&sa=X&oi=book_result&ct=result&resnum=11&ved=0CE4Q6AEwCg#v=onepage&q=Modeling%20for%20system%20and%20services&f=false
  • http://www.ofnisystems.com/Validation/Functional_Requirements.htm

Please be aware that the free essay that you were just reading was not written by us. This essay, and all of the others available to view on the website, were provided to us by students in exchange for services that we offer. This relationship helps our students to get an even better deal while also contributing to the biggest free essay resource in the UK!