Objectives This chapter provides you with a broader understanding of some important issues of Systems Design. It elaborates on the fundamental principles.

Objectives This chapter provides you with a broader understanding of some important issues of Systems Design. It elaborates on the fundamental principles presented in the previous chapter and introduces new Objects-Oriented topics Such as:- - Modeling System and Object behavior - Design Principles and Design Patterns - Designing Enterprise-Level Systems including Web-based Systems. Statechart Diagram describes the collection of “States” of each object. The Status Condition of each object are an important piece of information that an Analyst can use to help define the Business rules to be implemented in the Computer System. - Explain why enterprise-level systems require special design consideration - Apply UML deployment architectural notation to Web-based systems - Explain how Web services work to obtain information on the Internet Object-Oriented Analysis and Design with the Unified Process

Modeling System Behavior and Method Logic with Statecharts
Class Diagrams are used to make Program structure and Database Schemas easier to understand Use Case Diagrams and Interaction Diagrams describe basic Business and System Processes Statecharts were used in the Requirements discipline to capture various “Status conditions” of Business Objects. Statechart plays two important roles during the Design:- a) Statechart helps the Analyst to define an understand the “ Behavior” of the System Class and other Utility and Service Classes (Example: System Class, Windows menus, Authentication and Security Classes, Error-handling Classes) b) Statechart helps Analyst to define the “Method Logic” They provide components that allow the Designer to describe additional documentation to help the Programmer to write program Code later. The “Action-expressions” in Statecharts contain information that help define Method Logic. Object-Oriented Analysis and Design with the Unified Process

System-Level Statecharts
A Statechart can be developed for the System itself. This will allow Analyst to designate the States of a System. Statechart for the System can be designated for the‘States and Processing Controls’ of a system including :- Which Menu items are enabled or disabled Which Windows are modal (Window that must be responded to and closed before the system will respond) Which Tool bars and Icons are active You may have to sketch out many Statechart fragments to describe and document Processing Control rather than creating a massive single Statechart. (One of the strengths of Models is that you can sketch out partial models containing only the immediately relevant points) Object-Oriented Analysis and Design with the Unified Process

Logon Statechart for a Computer system The System opens with Transition startProgram() and immediately enters the Locked state. An Actio-expression is attached to the entry into the State, which indicates that System is to display the Logon Window. (/entry:display logon window). The System sits in that State until logonSent () Transition occurs.Then the System enters the Verifying User State. Again an entry Action-expression indicates that the System should access the Databse to verify the User. Exit Transition out of this State either return to the Locked State or move forward to the Unlocked state.. If the Logon is rejected, the System displays the Logon window again with appropriate Error message.. Otherwise , the menu is indicated for the User to continue using the System. Notice the associated Action-expressions on each Transition indicating what the System must do before completing each Transition. Object-Oriented Analysis and Design with the Unified Process

System-Level Statecharts
State Variable: Is an additional Attribute on the Design Class that is included to record a value of a “Current State” to inform a System which Items to enable or disable and which Message to process or ignore. (e.g: A variable called systemstate holding values such as “Locked”, “Verifying User”, “Unlocked” etc.. Statechart allow the Designer to depict complex System Behavior with Nested States within other States and Multiple Parallel Concurrent States e.g. The Behavior of User Interface is quite complex How does a Designer know How and When to enable and disable Menu Items? (It is normal to enable and disable Menu Items to control what the User is allowed to do in a Network-based System) Object-Oriented Analysis and Design with the Unified Process

Messages, Transitions, and Methods
Statechart provide components that allow the Designer to describe the internal activity or ‘Logic of a System Object’. Specifying this Logic provides additional documentation to help Programmer to write code later. The Message on a Sequence Diagram, Transition Trigger in a Statechart Diagram and a Method Signature in a Design Class are very closely related. Thus Method and a Transaction must also be closely related since:- a) A Message causes a Transition trigger to fire. b) A Message to a Destination Object is also the Source for defining a Method Signature. Because of the close relationship between Transition and Methods it should be evident that the Action-expressions on the Sytatechart can be used to help define the Logic within a given Method. Object-Oriented Analysis and Design with the Unified Process

Comparison of Methods, Messages, and Transitions
Object-Oriented Analysis and Design with the Unified Process

Design Statecharts extend Requirements Statecharts
Design Statechart includes:- Action-expressions which can be used by a Programmer to help develop the Method Logic. Transitions that allow the Object to remain in the same State Temporary States for Inter-model consistency Decision Pseudostate is a diamond notation on a Statechart; indicating a decision point on a path New Transitions out of Decision Pseudostate may have no Trigger (i.e may fire automatically) Object-Oriented Analysis and Design with the Unified Process

DESIGN STATECHART - Action-expressions and Method Logic
A Sequence Diagram may not contain enough internal details about a Method. However Statechart Diagram can provide all of the relative Processing information on the Sequence Diagram through the use of Action-expressions. Action Expressions describe the Actions that must occur during the Transition from one State to another. In other word Action Expression is a statement of some Activity that the Object performs before the Transaction is completed. The Benefit of Action-expressions is that they document what Method Logic will be required during Programming. Object-Oriented Analysis and Design with the Unified Process

Sequence Diagram for the Telephone Order scenario of the Create new order Use Case

DESIGN STATECHART All the information on the Sequence Diagram should be in the Statechart. In the Sequence Diagram four messages are sent to an Order Object createOrder() , addItem(). CompleteOrder() and makePayment(). On the Statechart Diagram:- A Transition called createOrder(). This Transition creates a newOorder and places it in the Open for Item Adds state. The addItem() Transition corresponding to the Message of the same name., causes an order to add line items, but it also remains in the same State. Using a Transition in this manner – to capture a Message and perform an Action but allow the Object to remain in the same State- permits the Object to handle multiple addItem Message. completeOrder() moves the object to a new state, Ready for Shipping. makePayment() does not have a corresponding Transition in the Statechart. In this situation the Statechart needs to be enhanced to ensure inter-model consistency. If we want to allow multiple makePayment () transitions, we could add a Transition that leaves and returns to the same State, such as the Ready for Shipping State. Another alternative is to add a new State – A Temporary State.- for the Object to move to , after the Payment is made.( We choose the alternative option and add a new State called Ready for Payment prior to Ready for Shopping State. Object-Oriented Analysis and Design with the Unified Process

Original Statechart for Order
Two modifications will be done to this original Statechart to conver it into Design Statechart by adding Decision Pseudostate and Action-expression. Object-Oriented Analysis and Design with the Unified Process

Design Statechart for Order

Design Principles-Protection From Variations
Good Design is based on two Factors:- - Good Design Principles - Standard Design Patterns GOOD DESIGN PRINCIPLES - Object Responsibility Coupling and Cohesion Protection from Variations Indirection Systems that are based on Good Design Principles are not only easier to develop and put into operation but are also much flexible, easy to maintain and extend. Object-Oriented Analysis and Design with the Unified Process

GOOD DESIGN PRINCIPLES
As a Designer you must identify the Responsibilities of each Class since thePrinciple of Object Responsibility is one of the most important An Object’s Responsibility may be:- - Maintain its own Attributes, including getting information from other Objects, when needed to fill in values. - Create Objects that depend on it - Be expert on certain sets of information (i.e Have the needed information or have Navigation Visibility and access to the other Objects that do have the information) The other Object Principles are:- Coupling The objective of Coupling principle is to couple the Classes that need to work together, but not to have excessive links between Classes. Coupling relates to the idea of links between Classes. Coupling must always be considered from the perspective of an entire System. Cohesion. A Cohesive Class is one whose set of Responsibilities and – Methods- are closely related. The Functions that are assigned to the Class and that are executed through the Methods are focused. Object-Oriented Analysis and Design with the Unified Process

Additional Design Principles
Developing Software Systems is difficult and complex. Developers can not always develop Systems that work correctly and solved the right Business problem. Every System requires constant modification and upgrading . Perhaps functions that were not added in the first version need to be added later or errors need to be fixed. May be Business requirements have changed and the System needs to be upgraded. Systems that are developed based on Good Design Principles are not only easier to develop and put into Operations the first time but also much easier to maintain. The following Additional Principles enhances the flexibility, ease of maintenance and extensibility of a new System:- Protection from Variation Indirection As a Designer continually think about ‘Protection From Variations’ and apply the Principles as you design- During the User-interface design , Program Logic Design and Database design. Object-Oriented Analysis and Design with the Unified Process

Additional Design Principles
PROTECTION FROM VARIATIONS A Principle of design that whereby parts of a System that are unlikely to change are segregated (or protected) from those that will need to be changed. As you Design the System you should try to isolate the parts of the System that are likely to change from those that are more stable. Protection from Variation is one of the Principle that drive the Multilayer Design Pattern. Designers could mix all of the User-Interface Logic and Business Logic together in the same Class often in the Windows Input forms as in the early days of Visual Basic and PowerBuilder to build Graphical User Interfaces (GUI). The problem with this design is that when a User-Interface needed to be updated all of the Business Logic also had to be rewritten. Also, when the updates to the business requires the addition of new Classes and new Methods will create ripple effect of changes throughout the User-interface Classes.; since the User- interface Classes were tightly coupled to the Business. A better approach is to decouple the User-interface logic from Business logic. Thus, the Business logic being more stable is Protected from Variations in the User Interface. Multi Layer Design is a solution to the Protection from Variation in the event of Addition of new Classes or Methods as a result of Business Update requirements. Since, the User Interface (i.e. View Layer) sends all of its input Messages to the Use Case Controller, changes to the Methods or Classes in the Business Logic and Domain Layer are isolated to the Controller Class. Object-Oriented Analysis and Design with the Unified Process

Additional Design Principles - Indirection
INDIRECTION Principle of Decoupling two Classes or other System Components by placing an intermediate Class between them to serve as a Link. Although there are many ways to implement Protection from Variations, Indirection is a frequently used Object-oriented Design Principle to Protect stable components from Variations and also reduce Coupling. By Inserting an intermediate Object allows any variations in one System to be isolated in that intermediate Object. INDIRECTION is a Principle that applies to many Corporate Security Systems allowing Security Controls to be put in place to protect the System. Such as Firewalls and Proxy Servers are used by many companies to receive and send Messages between an Internal Network and the Internet. A Proxy server appears as a real Server, ready to receive Messages such as and HTML page requests. However, Proxy is a fake Server which catches and redistribute the Messages to the recipient. Object-Oriented Analysis and Design with the Unified Process

Importance of Design Patterns
Design Patterns are Templates is used to speed Object-Oriented Design. Patterns are created to solve problems. Over time and with many attempts, those working on a particular problem develop a set of solution to the problem. The solution is generally enough so that it can be applied over and over again and then becomes accepted as a standard. The use of Standard Design Templates (Design Patterns) has become very popular among Software developers because they can speed up OO Design work. (Examples of Standard Design templates:- Use Case Controller and Three-Layer Design) The two most popular primary Enterprise platforms (i.e Java and .NET) have set of Enterprise Patterns. Object-Oriented Analysis and Design with the Unified Process

Patterns exist at various level of Abstraction. At the most Concrete level, a Pattern may be a Class Definition with Code to be used by a developer. (eg. Use Case Controller) Concrete Level Patterns defines a specific Class or Classes that act as the switchboard for all incoming Messages from the environment. (Many ways can be used to implement the Controller Pattern. A Single Controller Class can be defined to handle all Messages from View Layer to Domain Layer or a Specific Control Class is defined for each Use Case or some combination of the two Method) At the most Abstract Level a Pattern might only be an approach to solve a problem. (eg. Multilayer Design Pattern tends to be more abstract) Object-Oriented Analysis and Design with the Unified Process

The Specification for a Pattern should contain at least five main elements The Pattern Name, The Problem that requires a Solution, The Solution, or explanation of the Patterns, Examples of Pattern The Benefits and Consequences of the Pattern The following Design Pattern figures shows these five elements Object-Oriented Analysis and Design with the Unified Process

Pattern Description for the Controller Pattern

Basic Design Patterns The authors of Elements of Reusable Object-Oriented Software, referred to as the Gang of Four (GoF) developed a basic classification scheme for Patterns based on Scope of Pattern (Class-Level Patterns or Object-Level Patterns) (See next Figure) Scope of Patterns Defines whether the design is for Class Level or Object Level Pattern. Class Level Scope of Patterns define solutions that do not actually instantiate Objects Object Level Scope of patterns apply when the implementation of the pattern results in specific objects being instantiated from classes. Type Of Patterns Creational Patterns helps assign responsibilities to Classes to instantiate new Objects - Structural Patterns provide solution to meet the architectural patterns help solve problems associated with Indirections. - Behavioral Patterns provide solutions to problems related to the way Internal System process executes. Object-Oriented Analysis and Design with the Unified Process

Classification of Design Patterns

Basic Design Patterns The (GoF) Patterns are some of the most fundamental and important, many other patterns like Java and .NET are also frequently used. To help you understand Design Pattern we will explain one Patterns from Creational , one Pattern from Structural Pattern and one from Behavioral Pattern. - Singleton Patterns, Adaptor Patterns - Observer Patterns Object-Oriented Analysis and Design with the Unified Process

Singleton Pattern Some Classes must have exactly one instance (For example A Class that Starts up the System or main Window Class). These Classes must have only one instance, but since they are instantiated from one place, it is a simple matter to limit the Logic to create only one Object. Other Classes Like Service Classes must have exactly one instance but cannot be easily controlled by having only one place to invoke the Constructor. These Classes manage a System Resource such as Database Connection. And invoked by many other Classes and from several different locations throughout the System. The Singleton Pattern provides a solution in which a Class itself controls the creation of only one instance. The approach of the Singleton solution is that : The Class has a Static variable that refers to the Object that is created A Method such as “getinstance” is used to get the reference to the Object. The first time “getinstance” Method is called it instantiates an Object and returns a reference to it. On latter call the Method , it simply returns reference to the already instantiated Object. All Constructors must be specified as Private in order to ensure that :- - Only one Instance is created No Other Class can accidentally invoke it. The Singleton Pattern is represented by Code in the Singleton template , To specify Singleton in your design , you should stereotype the Class as a “singleton” in your design. Object-Oriented Analysis and Design with the Unified Process

Figure - Singleton pattern template

Adaptor Pattern Adaptor Design Patterns Plugs an “External Class” into a System. External Class could be a variable Class. It could be replaced by an upgrade or an entirely different Class. The Method Signatures on the External Class are different from the Method names that are being called from within the System, The Adapter Class is inserted to convert the Method Calls from within the System to Method Names in the External Class. An <<interface>> Stereotype is frequently used to specify and enforce the use of correct Method names Adaptor Class inherits Method names from the <<Interface>> Class and provides Method Logic for those Methods. Each Method then extends to the final Method name in the Domain Class (It translates the Method names from one to another). Adapter Design Patterns is a standard solution for Protection from Variations since it Insulates the system from frequently changing Classes via an Adaptor Class. Adaptor Design Pattern is an excellent way to insulate system from frequently changing Classes by upgrading or by an entirely different Class.. It is a powerful solution to making System more maintainable. Eg. For an Internal Payroll System the Designer might purchase a set of clases to calculate all of the complex income tax deductions. Knowing that those classes could be replaced at a later date if the Tax Law changes, a Designer would be wise to create an |Adaptor Class between the System and the Tax Calculations Classes. Object-Oriented Analysis and Design with the Unified Process

Adapter Pattern Template
The Classes within the System use Method names such as getSTax () and getUTax () to access the Tax routines. The ABC Tax Calculator Class has Method names of findTax1 () and findTax2 (). The two UML Diagrams in the middle represent the Adaptor. The Top Class is an Interface Class.An Interface is necessary to specify the names of the Methods iIn order to enforce the use of correct Method names. The second Adaptor Class then inherits those Method names and provides the Method logic for those Methods. The body of each Method simply extends a call to the final Method Names of findTax1 () or findTax2 (). It adapts or translate the Method names from one to the other. Object-Oriented Analysis and Design with the Unified Process

Observer Pattern Observer Pattern is a fairly complex Pattern, but it is widely used and critically important.. It is also known as “Listener Patterns” as well as “ Publish / Subscribe”, or even “Callback Technique”. The Observer Pattern has been used with all types of System Development , even before O-O techniques were used. General, the View Layer Classes have Navigation to the Problem Domain Layer Classes. However when the design is being developed, it is better if the Domain Classes are not Coupled to the View Layer Classes. Thus even two Domain Classes have Navigation Visibility they should not be able to send messages to each other directly. Normally along with the Original domain Class , a Designer develops an Interface Class to provide the Method signature often this interface is called “Publisher”. The Listener Class (Window Class) can then inherit from the <<Interface>> Class to define the Method Signature. The Concept of Observer , or Listener Pattern is to allow a Widow Class to listen to a Domain Class for any changes . When the Class hears of a change it updates the appropriate fields. For the Listening to work :- The Domain Class must contain mechanism to:- Allows other Classes to “Subscribe as Listeners “Publishes” the changes to the Listeners when they occur. Must have an array of Object references that have subscribed as Listeners. Must have a specific Method Name Such as:- “addOrderListener” which can be called subscribed Listeners. Also another Method named “notify ( )” sends a message to each Object referenced in the array. The Windows Class (Listener Class) Sends a ‘reference of itself’ to subscribe as a Listener Implements the Method to be invoked when notified Inherits the Method Signature from a Class called the “Publisher”. Object-Oriented Analysis and Design with the Unified Process

Observer Pattern Observer Pattern is used to handle Dynamic and Temporary Linking which is an effective technique to avoid Permanent Coupling in place where it could cause problems. - This Pattern is used exclusively to handle Event Processing by Window Objects All Windows GUI Event-Processing capability is built around the Observer Pattern. - Class Window Libraries for Java and (.NET) are all implemented using the Listener Pattern as fundamental Event-handling technique. Observer Pattern allows two Objects to link dynamically Keeps Coupling low in a System, while still provides capability between Objects that should not be permanently linked. Object-Oriented Analysis and Design with the Unified Process

Observer Pattern Template

Three Classes in the Create new Order Use Case
Note: Order does only have visibility to Order Window not visibility to Customer Window AS Items are added to the Order the Current Order Amount and the Year-to-date Purchases fields need to be updated on the Customer Window. But Order does not have Navigation Visibility to Customer Window! The Observer Pattern will solve this problem by allowing the Customer Window to “Listen” for any changes to the Order Object Object-Oriented Analysis and Design with the Unified Process

Implementation of the Observer Pattern
When a Customer Windows wants to subscribe as ”Listener” it will call “addOrderListener” Method and sends a reference to itself as a parameter The Logic of “addOrderListener” Method adds the reference into the parameter array. The Ordered Class Method “notify () “ iterates through the array and sends a message to each referenced in the array. The “Interface” Order Listener (Observer Pattern) provides a Method Signature that will be called by Order Object. The Customer Window (Listener Class) can then inherit the Method from <<interface>> OrderListener to define Method signature. Object-Oriented Analysis and Design with the Unified Process

Designing Enterprise-Level Systems
Enterprise-Level Systems share components among multiple people or groups in an organization. Enterprise-Level Systems almost always use Multiple tiers of Computers Two major categories of Systems fits into Enterprise-Level System definition in relation to System Design:- Client/Server Network-based Systems Internet-based Systems Similar Properties between Client/Server and Internet Systems Both requires a Network Have Central Servers Have View Layer on Client machines Differences Between Client/Server and Internet Systems It is important to distinguish between C/S and Internet-based Systems because the Designer has to consider important Design issues. Primary difference is in how View Layer interacts with the Domain and Data Access Layers. The figure shows the three fundamental Differences between the C/S and Internet Based Systems. Object-Oriented Analysis and Design with the Unified Process

Differences between Client/Server and Internet Systems

Differences between C/S Systems and Internet
STATE-BASED or STATEFUL SYSTEM (C/S Network System) The concept of State refers to the permanence of connection between the Client View Layer and the Server Domain Layer. If connection is permanent as in the Client/Server System., Values in variables can be passed back and forth and are remembered by each components in the System. The View Layer has direct access to the Data fields in the Domain Layer (e.g Order data such as line item descriptions , prices etc displayed on the Form.) STATELESS SYSTEM (INTERNET SYSTEM) The Client View Layer does not have a permanent connection to the Server Domain Layer such as Internet Based Systems. (Transient Connection) Client requests a Screen via URL address typed in the Browser, the Server sends the appropriate document and then the two disconnects. (Client does not know the State of Server, and Server does not remember the state of the Client.) To add more permanence to the Stateless environment, Web Designers developed other techniques such as “Cookies” and “Session Variables”., which must be considered when designing an Enterprise Level Internet- based System. Object-Oriented Analysis and Design with the Unified Process

CLIENT CONFIGURATION The Client Configuration concerning the Client side of a Network-based System. Client/Server Network- Based System Client Configuration Consists of View Layer Classes and often Domain Layer Classes (Formatting, Displaying and Processing are all directly controlled by the View layer and Domain Layer Logic.) View Layer and Domain Layer Classes communicate directly with each other . Even if the Domain Layer is split across Tiers a permanent communication link can be established - all under the program’s control. Internet-based System All Screens are displayed by Browser (Formatting, display and processing must conform to Browser capability) Special Tools and Techniques such as Script languages, Applets have been developed to stimulate the Network-based capability Object-Oriented Analysis and Design with the Unified Process

Server Configuration Network- Based Systems - Server Configuration in a Network-based C/S Contains Data Access Layer Classes and sometimes Domain Layer Classes. - Classes collaborate through direct communication and access to each other’s Public Methods. Internet-Based Systems Communication among Classes is not direct. All communication from Client Tier must go through the HTTP Server. Methods and Program logic are indirectly invoked through passing Parameters The Indirect technique of accessing Domain Layer Logic is more complex and requires more care in System Design. Object-Oriented Analysis and Design with the Unified Process

UML Notation for Deployment Diagrams
The implementation of an Enterprise-Level Systems concern both with the Physical Components of the System as well as how the System is to be partitioned into executable components. UML Diagrams that depict Physical Components of the system are called Implementation Diagrams. IMPLEMENTATION DIAGRAM There are several type of Implementation Diagrams including Deployment Diagram. DEPLOYMENT DIAGRAM A type of Implementation Diagram that shows the deployment of various Physical components across different Locations. Object-Oriented Analysis and Design with the Unified Process

UML Notation for Deployment Diagrams
COMPONENT Component is an Executable Module or Program, it consists of all Classes that are compiled into a single entity. Component has well defined interfaces, or public methods that can be accessed by other programs or external devices. The name of the Component is underlined. APPLICATION PROGRAM INTERFACE (API) A Component has an Application Program Interface (API) that contains the set of Public Methods that are available to the outside world. NODE Is a physical Entity at a specific Location such as a Computer etc… The Name of the Node is listed inside and underlined. FRAMESET Is a high-level Object that holds items to be displayed by a Browser The Stereotype <<frameset>> indicates a Web Page. Object-Oriented Analysis and Design with the Unified Process

UML Component Notation

UML extension for Frameset
UML Node Notation UML extension for Frameset Object-Oriented Analysis and Design with the Unified Process

Simple Internet Architecture
The Simple Internet Architecture allows Users to view static information on the Web or other Internet Locations. The Two Nodes represent two separate Computers (i.e. Client Computer and Server) The Browser and Server are key elements that transport all information between the Client and Server Computer. On the Client Computer the Browser Component is executing On the Server Computer, the Internet Server Component is executing The Browser requests a Page . Pages reside on the Server and are sent to the Browser for display. Pages indicated by <<frameset>>. Within the Page, Program Logic is inserted through the use of JavaScript, VBScript, Java Applets, or ActiveX controls. Object-Oriented Analysis and Design with the Unified Process

Simple Internet Architecture

Two-Layer Internet Architecture For User Interaction
To support a Business application the System must be able to respond to other User Requests – To accept inputs and events from the User, Process these inputs and respond with a meaningful output. A Two-layer System accepts inputs and requests from Users. Process these requests, including updating the database and display the result The Structure for the Internet-based Systems should be similar to Two Layer System Architecture. where:- The Domain Layer and Data Access Layer are usually combined Business Logic in the Domain Layer frequently relates only to be Formatting of the Data and deciding which Database table to update. Input data is sent to either a Common Gateway Interface (CGI) Component or an Application Component. (these components are similar) Object-Oriented Analysis and Design with the Unified Process

Two-Layer Internet Architecture For User Interaction
CGI Directory contains compiled Programs that are available to receive Input data from the Server. This technique is very effective and usually has very quick response and processing time Despite the fact that it involves with complex programming. CGI Programs process Input data, Access Database and Formats a Response Page in HTML. URL is a potential Direction for Input data for a Web Page with embedded program code. The User-Interface Classes often contain the Business Logic and Data Access. Due to the structure of Web Servers, the Program that process the Input forms also outputs the HTML code that is sent back to the Client Browser. Processing takes place with Servlets (i.e for Java a Java Servlets) Servlets usually include Business Logic and Data access) Every Web Form has a “Code Behind Class” written in VB, C# or similar languages . The Code Behind the Class receives the data from the Web form, processes the data and formats the output as HTML page. Object-Oriented Analysis and Design with the Unified Process

Two-layer Internet Architecture For User Interaction
Some inheriting complexities exist with the Two-layer Internet Architecture:- The Processing Logic and Data Access Code is embedded within the HTML Pages, which are also User-interface Pages. In The HTML Page all Three Layers are mixed together. Since HTML Page could potentially contain User-Interface Controls, User-Interface Logic. Problem Domain Logic and Data Access Logic. Many Internet Systems that have been built with this Architecture are complex, difficult to test and maintain. Object-Oriented Analysis and Design with the Unified Process

Two-layer Internet Architecture
The Extensions shown on the Response Page <<Frameset>> indicates what type of Program code is embedded in the page. Depending on the type of Extension Language an Application Server (Language Processor) is invoked to process the embedded code, Object-Oriented Analysis and Design with the Unified Process

Three-layer Internet Architecture
For Systems that require more complex Business Logic it is better to add Domain Layer with separate Classes for both the Domain Logic and Data Access. Three-Layer Architecture is more appropriate for Systems that need to support multiple User Interfaces both Internet-Based Systems and Client/Server Based-Network Systems. The Three-Layer approach can be implemented by defining separate Domain Layer and Data Access Layer Class on the Common Gateway Interface. A Use Case Controller is identified for each Input Form to receive and distribute Messages to the individual Objects of the System. On the Application Server side the Programmer has less direct control . However tools like (Java tools: Java Server Pages and Java Servlets and ( .NET) tools: Common Runtime Language and Code) makes development faster and easier. Object-Oriented Analysis and Design with the Unified Process

Three-layer Internet Architecture
Java Servlet is a Java Program invoked by the Application Server to executes Java Server Pages which have (.jsp) extension. Java Servlet identified for the Input Form can be a Use Case Controller, which can then distribute the Input Message to other Domain Classes to process the request. After processing the Servlet takes control and formats the Output Response Page. For (.NET) Environment process is very Similar. The Input form is sent to ASP.NET Application Server, which invokes the ‘Code Behind Object’ (written in VB , C# or J#) to call appropriate Methods in other objects. The Program Modules in (.NET) environment are compiled into ‘Common Language Runtime’ Common Language Runtime is a mid-level language that allows Programs to be partially compiled and managed for faster execution. Object-Oriented Analysis and Design with the Unified Process

Three-Layer Internet Architecture
The major difference in the (.NET) Environment is that .(NET) Framework has an extensive Library Of Standard Components that does everything from automatically Authenticating Users to Accessing Data and Populating forms. This high level components provided by (.NET) make it easy to Program and build Forms. On the other hand; it makes it easy to mix the Layers by scattering Business logic in with User Interface Processes and Data Access Layer. BEST PRACTICE - Be sure to define the Problem Domain Classes first , before defining the Web Forms and User-Interface Pages. Object-Oriented Analysis and Design with the Unified Process

Three-Layer Internet architecture

Web Services Web Service is one of the new technique used in the development of Internet Based Systems. A Web Service is simply a Computer Program that provides a service to other Systems via the Internet and is posted in a Directory so that systems can find it. Requests for information goes to a Services Directory called Universal Discovery Description and Integration (UDDI) Directory which is an Indexing Service to help locate Web Services. UDDI provides the Internet Address of a Program offering that service Example : Suppose that your Application requires some data from an external Database such as the latest Financial information about a particular company. Instead of trying to maintain these data and keeping it current, you can access them from the other Service on the Internet. So as the program is executing it determines that it needs current financial data. It does not care where it gets these data., just that they be current. First the Program sends out a request for information. The request will go to the a UDDI Service Directory to help locate Web Services, The UDDI will provide an Internet address of a program that will provide that service. The Application will then request that desired information over the Internet. Object-Oriented Analysis and Design with the Unified Process

Web Services Searching Service Directory and requesting the desired information over the Internet has never been possible before for various reasons. One major obstacle was that the Requestors and Providers both had to use exactly the same format of data exchange. With Web Services the major obstacle has been solved since all communication in Web Services is based on XML (Extensible Markup Language) to allow for generic data exchange. XML is a text based language like HTML, The difference is that HTML has standard tags, where as XML can include self-defining tags to describe any data desired. The sequence and Format of the data are defined within the transmitted file itself. Thus the Recipient of the data can process the data no matter what the sequence. Web Service capabilities will expand very rapidly within the next few years. Object-Oriented Analysis and Design with the Unified Process

Invoking a Web Service Object-Oriented Analysis and Design with the Unified Process

Objectives This chapter provides you with a broader understanding of some important issues of Systems Design. It elaborates on the fundamental principles.

Similar presentations

Presentation on theme: "Objectives This chapter provides you with a broader understanding of some important issues of Systems Design. It elaborates on the fundamental principles."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Objectives This chapter provides you with a broader understanding of some important issues of Systems Design. It elaborates on the fundamental principles.

Similar presentations

Presentation on theme: "Objectives This chapter provides you with a broader understanding of some important issues of Systems Design. It elaborates on the fundamental principles."— Presentation transcript:

Similar presentations

About project

Feedback