Analyzing Requirements and Defining Solution Architectures by malj

VIEWS: 8 PAGES: 22

									Analyzing Requirements and Defining Solution Architectures



1. BUSINESS REQUIREMENTS ANALYSIS
PROJECT SCOPE
(Analysing Requirements)



If your browser doesn't support inline frames click HERE to view the full-sized graphic.



Define Project Responsibilities then:

          Divide Responsibilities into individual tasks
          Determine how many Geographical Areas will be involved
          Get estimate of number of people who will be using your application
          Understand how quickly client wants the application implemented




ANALYZE THE EXTENT OF BUSINESS REQUIREMENTS
(Design dealing with client's line of business)

Establish Business                  Description of a specific task in client's business
Requirements                         work flow. e.g., inventory control,
(Rules)                              inventory falling below a certain amount, re-order
                                     stock.

Establish Type of                   Identify where problem lies, e.g. When to re-order
Problem                              stock, only states to do it, not how to do it.

Establish                           What the client wants
Customer Quality                    Use progressive solution – Solution implemented
Requirements                         in
                                     stages.

Cost-Effectiveness                  Minimize TCO (Total Cost of Ownership)
                                         o Consider the role of value
                                         o What constitutes a cost
                                         o Suspect and Recognise high costs
                                    Increase ROI (Return on Investment).




ANALYZE CURRENT PLATFORM AND INFRASTRUCTURE

          Analyze the technology already in use
          Consider input from staff (part of infrastructure) and should be part of solution



                                                                                               1
ANALYZE THE IMPACT OF TECHNOLOGY MIGRATION

     Schedule time required for migration process
     Test the effects of migration
     Minimize business interrupts during Migration
     Familiarize personnel with new changes
     Prepare contingency plans for unexpected failure
     Establish an Application environment
          o Infrastructure – Company's every part that is not a computer, cables, etc.
          o Hardware –and software constraints and requirements to run Applications
     Identify Organisational Constraints
          o Financial Constraints
          o Company Politics
          o Level of technical acceptance
          o Training needs
     Identify your audience
     Establish an Implementation Schedule




ANALYZE SECURITY REQUIREMENTS

     Consider:
          o Which groups requires access
          o Which data should each group be given access to
          o What kind of access should each group be given
     Identify roles of Administrators, Groups, Guests and Clients
     Establish level of Fault Tolerance / Security Context
          o Level of accepted data safety
     Identify Impact of Security
          o Will your system disable the functions of existing Software, etc
     Plan for Maintainability
     Plan distribution of a security Database
     Plan for Auditing / Logging
     Identify required level of security needed
     Analyze existing Security Policies




ANALYZE PERFORMANCE REQUIREMENTS

     Consider:
         o Interoperability with existing standards
         o Response Time expectations
         o Transactions / minute
         o Bandwidth
         o Capacity
         o Bottlenecks
         o Peak vs. Average requirements




                                                                                         2
ANALYZE MAINTAINABILITY REQUIREMENTS

     Consider:
         o Deployment
         o Maintenance
         o Redeployment




ANALYZE EXTENSIBILITY REQUIREMENTS

     Consideration for future growth




ANALYZE AVAILABILITY REQUIREMENTS

     Consider:
         o Hours of operation
         o Level of availability
         o Geographic scope
         o Impact of downtime




ANALYZE HUMAN FACTORS

     Consider:
         o Physical environment constraints
         o Accessibility
         o Special needs
         o Target users
         o Roaming Users
         o Help Support
         o Training Requirements




ANALYZE INTEGRATION REQUIREMENTS

     Consider:
         o Legacy applications
         o Compatibility with existing software
         o Format and location of existing data
         o Data conversion
         o Data enhancements




ANALYZE EXISTING BUSINESS PRACTICES

     Consider:



                                                  3
           o   Current business practices
           o   Customer's needs
           o   Budget
           o   Implementation and training
           o   Quality control requirements
           o   Process engineering
           o   Legal issues




ANALYZE SCALABILITY REQUIREMENTS

      Consider:
          o Growth of data, organization and audience




2. TECHNICAL SOLUTIONS / ARCHITECTURE
IDENTIFY THE APPROPRIATE SOLUTION TYPE / TIER

Single-Tier Application Model

      Business rules, User Interface and Database is on the client computer.
      Negative side:
          o High network traffic loads
          o Difficult to maintain
          o Single PC




Two-Tier Application Model

      Business rules (B/R) and user interface (U/I) is on client
      Client makes intelligent queries and processes them
      Database (Data) is only kept on server for central storage
      Advantages:
           o Client/server network advantages
           o Separates user interface processing from data storage




N-Tier / Multiple – Tier Application Model

      Presentation, Business and data services are split



                                                                                4
">

If your browser doesn't support inline frames click HERE to view the full-sized graphic.




MEETING USE CASE SCENARIOS
(Which technologies are appropriate for implementation of a given business solution?)

ELECTRONIC DATA                                     Method of transferring structured data
INTERCHANGE (EDI)                                    between two computers by electronic
                                                     means

THE INTERNET                                        Consider OSI (open System
                                                     Interconnection) standards:
                                                         o Defines networking framework
                                                             by implementing seven layers
                                                             of protocol (Physical, Data,
                                                             Network, Transport, Session,
                                                             Presentation, Application)
                                                         o Handy Acronym: "Paula Did
                                                             Networking Till She Passed
                                                             Away"

POSIX (PORTABLE                                     Set of IEEE and ISO standards
OPERATING SYSTEM                                     defining an interface between
INTERFACE FOR UNIX)                                  programs and operating systems

SOLUTIONS IN USE CASE                               Enterprise Solutions
SCENARIOS                                                o Spread across entire scope of
                                                              a business enterprise
                                                    Distributed Solutions
                                                         o N-Tier Architecture – different
                                                              components perform different
                                                              parts of
                                                              a task
                                                    Centralized Solutions
                                                         o Stand alone applications
                                                              where minimal shared
                                                              information is required
                                                    Collaborative Solutions
                                                         o Involves multiple
                                                              software/hardware packages
                                                              that must function
                                                              interactively



CHOOSING DATA STORAGE ARCHITECTURE



                                                                                              5
      Consider:
          o Amount of users accessing at same time
          o Storage capacity
          o Transactions / minute
          o Database Growth
          o Available security features
          o Reporting requirements




FEASIBILITY TESTING

      Evaluation to ensure that the solution meets the business expectations and use case
       scenarios are met. Demonstrates workability of technical architecture.
      No code written yet.
      Must ensure the following are met:
          o Business requirements
          o Use case scenarios
          o Existing technology constraints
          o Impact of shortfalls




CONCEPTUAL AND LOGICAL DESIGN

      Every solution design must be evaluated in terms of:
          o Availability
          o Extensibility
          o Maintainability
          o Performance
          o Scalability
          o Security




DEVELOP AN APPROPRIATE EDPLOYMENT STRATEGY

      Break down application in series of phases/versions
      Plan test environment for each test phase
      After testing plan a test rollout – Dry run of how you will implement product
      Execute the test rollout
      Deploy this phase to the production environment
      Collect and analyze bug reports
      Fix Bugs
      Repeat from second step (Plan test ...) for next phase of product




3. DEVELOPING DATA MODELS
DBMS (Database Management System) - Computer Application providing the means and
methods to permit a user to interact efficiently with a data source



                                                                                             6
Types of DBMS Methodologies:

Flat-File

       e.g. Telephone directory
       Data is stored in one large file
       Relies on standard file I/O processes
       Contains only one record structure
       Uses no links between separate records
       Relatively fast
       Can become very big and hold redundant data

 Customer       Discount        Order         Shipping       Accounts
   Data          Terms          Record         Data          Payable




Hierarchical Database

       Single flat file is replaced with series of tables linked in a
        structured relationship
       Child record can be linked to only one parent
       Link between a child and parent record is permanent
       Child records can only be reached through a parent record




Relational Database

       Stores data in one or more tables which can be linked to any
        other table
       Consists of Entities (Tables), Fields (Columns) and Records
        (Rows)




Types of DBMS Methodologies:

       Analysing the relational data structure of a database use ERA
       ERA assists in defining three things about data:
           1. The entities described
                     Anything that contributes to the cycle of a business process and
                        can be described in terms of accessible data, eg: Cheque Book
                     Three types:




                                                                                         7
                            1. Kernel entity – describe only one entity, not used to
                                define relationships
                            2. Associative entity – ties kernel entities together
                            3. Characteristic entity – provides additional information
                                about a specific kernel/associative entity
           2. The attributes of the entities
                   When describing an entity you refer to its
                       attributes/characteristics – single invisible item describing
                       aspects of an entity
           3. Relationship between the entities
                   Linking one table with another for queries
                   Makes use of two keys:
                            1. Primary Key – Unique value for each record in the
                                entity, referenced by,
                            2. Foreign Key - Corresponds to PK of another entity
                   One-To-One Relationship
                   One-To-Many Relationship
                   Many-To-Many Relationship
                   Joining entities - five types:
                            1. Inner Join - Relates two tables together and returns all
                                records from each table that have a matching
                                record in another table
                            2. Left Outer Join - All records in the left table are returned, but only
                                matching records from the right table are
                                displayed.
                            3. Right Outer Join - Opposite to Left Outer
                            4. Full Outer Join - Returns all matching records from both tables,
                                but nulls are placed where other records are
                                retrieved, but do not match
                            5. Cross Join - Two tables are related but a set of fields to relate
                                to is not provided. All possible combinations of
                                all rows in the table is made = Cartesian Product




APPLYING NORMALIZATION
(Process of removing redundancies from stored data)

Advantages:            Saving in storage space and cost
                       Data can be updated and maintained efficiently




                                                                                                   8
Rules of               First Normal Form
Normalization =             o No repeating groups. Data in rows and
Normal Forms:                   columns must
                                contain only one value
                            o Every record in the table must be unique
                                and no duplicates are
                                permitted
                            o PK must satisfy several conditions:
                                      No duplicates
                                      Can not contain Null values
                                      Every record must have a PK
                            o All data must be non decomposable – the
                                data can not be
                                broken down into simpler pieces
                       Second Normal Form
                            o Every field in a table must relate to its PK
                                field in its entirety
                       Third Normal Form
                            o Any non-key field in a table must relate to
                                the PK of the table
                                and not any other field

Denormalization        Restore attributes
                       Restore duplicate keys




APPLYING DATA INTEGRITY
(Refers to the accuracy and consistency of the data contained in a database)

Entity integrity       No component of a PK can be permitted to have a
                        null value

Referential            Guarantees the logical consistency of the database
integrity               by ensuring the values for PK and FK pointing to PK
                        are always in
                        agreement
                       Three rules that can be imposed when updating PK:
                            1. Restrict – Delete / Update on PK not allowed
                            2. Cascade – Any change to PK is
                                automatically applied to all FK
                            3. Nullify – Before update is done to PK all
                                corresponding FK values are set to null
                       CONSIDER BUSINESS RULES AND
                        CONSTRAINTS




4. PRINCIPLES OF USER INTERFACE DESIGN
WHAT MAKES A GOOD DESIGN?



                                                                               9
User Control     The user must be able to control everything about the
                 application.
Directness       The user must see direct results that they take in your
                 application.
Consistency      The Environment must be consistent eg: Windows 95/98
                 environment.
Forgiveness      Tell users before they make mistakes; e.g., Min/Close
                 button in Windows, difference in closing and minimising.
Feedback         Application must communicate with users, when busy, etc.
Aesthetics       Interface must be visually appealing.
Simplicity       Only show user what he needs, hide more complex
                 concepts until asked
                 for = progressive disclosure.
Accelerator keys Use of shortcut keys, eg: Alt & Ctrl – A keys.
Choose the             TabStrips
correct controls       Tool, Progress & StatusBars
                       Tree and ListViews
                       Sliders, text boxes, labels, etc.

Using MDI's /
SDI's
Adding Shell           File Object – Any item within the shell, e.g. Printers
extensions             File Class – Owner of particular type of object e.g.
                        MS Excel file is a file class
                       Handler – Code that implements a specific shell
                        extension
                             o Some shell extension types include:
                                      Context Menu Editor – Context
                                         menu appears when user clicks on
                                         a
                                         file object with the secondary
                                         mouse button
                                      Icon Handler – Adds icons to the
                                         classes for a specific file object
                                      Property Sheet Handler – Adds
                                         property sheet specific to a file
                                         class or
                                         file object
                             o Will you use Console Applications?
                                      e.g., TSR utilities
                                      Terminal emulators
                                      Hardware configuration utilities
                             o Accessibility – Visual/hearing impaired or
                                spelling impaired consideration
                                for users
                             o Deployment Platform Consider:
                                      32 Bit Windows or 16 Bit Windows
                                      Internet or Intranet, Browser
                                         compatibility, etc. must be kept in
                                         mind
                             o User assistance:
                             o Fully indexed and searchable help topics



                                                                                 10
                            o    Context-sensitive help – pressing F1
                            o    "What's this" Help, ToolTips, Status Bars
                                     Task Help (The assistant in MS
                                         Word for example)




5. DERIVING THE LOGICAL & PHYSICAL DESIGN
      Logical design = Theory and planning behind the design and implementation (Physical
       Design)
      Logical design is concerned with behaviour from an abstract perspective
      Physical Design is concerned with the actual implementation of the design
      Logical design is independent of technology constraints
      Physical design must consider system hardware and software where the interface will be
       employed




DERIVING THE LOGICAL/CONCEPTUAL DESIGN

      Requires that you begin with a structured base and evolve a solution that will
       provide a physical implementation satisfying business requirements
      Make use of the following models to structure your design:

1. Context Model:       The process that surrounds your application
                        Consider external interactions, draw a diagram of
                         the interaction between your application and other
                         business processes

2. Work-Flow            Describes the process your application supports
Model:                   rather than the process your application performs
                        To generate the model:
                             o Think of each Input an Output point in your
                                  context model as a client of your
                                  application.
                             o Consider the business tasks that each
                                  client must perform
                             o Eliminate tasks that are not the
                                  responsibility of your application
                             o Determine the sequence in which each
                                  task is performed

3. Task-                Describes internal flow of operation inside the
Sequence Model:          application
                        Reference the previous two models to generate
                         this model
                        The task-sequence model describes what your
                         application needs to do to generate the proper
                         inputs and outputs in a proper sequence



                                                                                           11
                                     Tasks in this model differs from the ones in the
                                      work-flow model in that these tasks are internal to
                                      your application, while the tasks in the work-flow
                                      model are external
                                     Focus on what the application does, rather than on
                                      what the users need it to do
                                     Draw a flow chart to outline the process:
                                     Actions(Rectangular boxes) to be performed
                                          o Decision points(Diamonds), contains a
                                              question with all possible
                                              answers
                                          o Connections(Arrows between action and
                                              decision points), direction
                                              of arrow shows sequence of the elements




                                                                 ">

If your browser doesn't support inline frames click HERE to view the full-sized graphic.




          Process of Logical design - defined as a discrete series of activities that includes:




1. Identifying                        The primary components for constructing a logical
business objects                       design
and services:
2. Interface                          An interface is a statement defining the elements
design:                                required to call a service, along with any
                                       preconditions along with the service

3. Business object                    Dependencies between business objects appear
interdependencies:                     when one business object calls for a service
                                       supplied by another business object
                                      Must be avoided at all times

4. Employing                          Usage Scenarios ensure that requirements in the
usage scenarios to                     conceptual view is fully and correctly expressed
validate logical                      Ensures clarity and correctness of the design
design
5. Design                             Producing a complete logical design does not
Revisions:                             happen in one step
                                      Begin by creating an initial design, then criticise
                                       and dissect it, refining the design and adding
                                       detail




                                                                                                   12
      Logical Design Risk Factors to Consider
           o Behaviour of the logical design does not match usage scenarios
           o Logical design must be co-ordinated with the enterprise architecture
               (Hardware/software)
           o Must not depend on external systems

      Baselining the Logical Design
          o Tests performed before making any changes to a system
          o Key requirement of baselining a logical design is validating the usage
               scenarios

      Asses the potential impact of the logical design by considering:
          o Performance
          o Maintainability
          o Extensibility
          o Scalability
          o Availability
          o Security




DERIVING THE PHYSICAL DESIGN

      Means translating the logical design into a cost effective solution
      Roles filled by teams in a physical design:
           o Product Management – Governs the physical design process
           o Development – Creates the design
           o QA/Testing – Plans test process
           o Logistics – Plans appropriate distribution
           o User Education – Plans training programs
      Assessing the impact of the design, consider:
           o Performance
           o Maintainability - considering:
                     Good three tier design
                     Designing for change
                     Business rules
                     Code readability
           o Extensibility – How new functionality can be added to the system with
                minimum cost and time impact
           o Scalability – e.g., Must perform the same if 10 or 1000 users makes use of the
                system. Consider:
                     Component state
                     Just in time activation
                     Clustering
                     Resource pooling
           o Availability – How often the system is able to perform, measured by
                MTBF (mean time between failure) and MTTR (mean time to recovery);
                consider:
                     Redundancy
                     Message delivery
                     Clustering – Use process of failover = quickly switching to a different
                         server if one fails
           o Security
      Physical design as a process: The process of turning a logical design into a physical
       solution and involves a sequence of events:


                                                                                                13
           o     Allocating services to components
           o     Distributing components across the network
           o     Refine component packaging and distribution
           o     Define component interfaces as a mechanism for implementing the service
                 relationship between components
           o     Determine physical media storage, how data will be accessed and
                 distribution of physical data
           o     Validate the design to ensure the physical design is consistent with the
                 logical design and overall enterprise design




6. THE SOLUTIONS FRAMEWORK
Composed of seven models:

1. Team Model:                  For building high performance teams that
                                 deliver
                                Team must know who does what
                                Must know who is in charge

2. Process Model:               Judging development trade-offs
                                Addresses explicit accountability for teams
                                Addresses project risks early in the planning
                                 stages
                                Defines critical milestones for tracking
                                 development
                                Characteristics:
                                     o Envisioning – Vision statement
                                         provides product/service goals
                                     o Planning – Defines customer
                                         expectations
                                     o Developing – Establish series of
                                         interim milestones, debugging,
                                         testing, etc.
                                     o Stabilisation – Rigid operational
                                         requirements for thorough testing

3.                              Designing for flexibility
Development/Application
Model:
4. Solutions Design             Aids developers in anticipating user
Model:                           requirements
                                Aligns solution development with business
                                 goals

5. Enterprise                   Provides structures for business integration
Architecture Model:             Consider:
                                     o Application Architecture – standard
                                        interfaces, services, etc.
                                     o Business Architecture – Describes
                                        how business enterprise operates



                                                                                            14
                                      o   Information Architecture – What
                                          information is needed by the
                                          organisation in order to run the
                                          business operations
                                      o   Technology Architecture

6. Infrastructure Model:         Guides system developers in system
                                  deployment

7. Total Cost of                 Methods to identify costs in technology
Ownership Model:                  investments
                                 Aimed at improving return on investment
                                 Consider:
                                      o Role of value
                                      o Cost discrepancies
                                      o Business enterprise requirements



7. DEPLOYMENT ISSUES

       Method of distributing your application
       Deployment Medium:
           o Floppy Disks Deployment (1.2 / 1.44/ 2.88MB capacity)
           o CD-ROM Deployment (650MB capacity)
           o Network Deployment - Consider speed, bandwidth and reliability
           o Internet Deployment – Webserver fulfils task of files server, user connects to
               server and downloads files
       Deployment Methods:
           o When installing over a network consider:
                     Push Install – Network server initiates process to send files to user
                     Pull Install – Client initiates some action to start copying the files from the
                         server
                     Automated Installs – Using Batch and Script Files or Systems
                         Management Server (SMS)




8. COM (COMPONENT OBJECT MODEL)
       COM is based on concept of re-usable components


ADVANTAGES IN THE COM

            o   More productive in using and reusing software
            o   Offers opportunity to develop for niche applications, e.g., Add-on components to
                existing applications
            o   For vendors, distributed operating systems can be tailored to user's needs
            o   End users have a wide variety of choices
            o   Corporate standpoint, component software can reduce costs for in-house
                development
            o   MS OLE standard was first step in the creation of component software



                                                                                                  15
COM COMPONENT SOFTWARE ARCHITECTURE

        o   All services supplied to users by COM, share a common requirement:
                  Access to mechanisms to allow compiled software vendors to connect
                     together
                     and to share information in a well behaved and defined manner
        o   COM supplies supporting mechanisms for:
                  Robust evolution of component-based applications and systems
                  Communications between components, between processes and across
                     network
                     boundaries
                  Dynamic loading of components
                  Error and status reporting
                  Shared memory management between components
        o   Component Software Problem:
                  Most fundamental problem in component software is providing a system
                     that
                     will allow binary executables
                  Five areas must be supported to supply a single supporting mechanism:
                           Basic Interoperability – Free creation of design, while still being
                               interoperable with other applications from different developers
                           Version Compatibility – Applications must be able to be
                               upgraded, without
                               all other components required to be upgraded as well
                           Language Independence – Applications must not be language or
                               tools
                               specific
                           Cross-Process Functionality – Components must be able to
                               function in-
                               process, cross process and cross-network
                           Performance – system overhead must not impact on
                               performance




BENEFITS OF COM INTERFACES

        o   Increased process speed and minimal overhead
        o   Reusable interfaces
        o   Local/remote transparency – allowing object to be local or networked
        o   Language independence
        o   Virtual function tables (vtables in memory) = COM can be adapted to a variety of
            platforms by defining the vtables = any language that supports function calls via
            pointers, e.g., C/C++, Pascal(Delphi) Small Talk, Basic and Ada can be used to
            write components




COMPONENT OBJECT INTERFACES




                                                                                            16
              o   All component objects must support a base interface – IUnknown- along with any
                  combination of other interfaces necessary to expose the functionality supplied by
                  the component object – Data aspects of components are never exposed
              o   IUnknown Interface:
                        Defined by all COM objects, provides the implementation necessary for
                          basic
                          COM functionality
                        Is base class to derive all other COM and OLE interfaces
                        Provides three exposed methods:
                               QueryInterface Method:
                                       Allows clients at run time to dynamically ask whether or
                                           not a specific interface is supported by the component
                                           object
                               AddRef Method:
                               Called to increment the component's use count when another
                                  component object is using the interface
                               Release Method:
                               Called when interface is no longer needed




COMPONENT OBJECT LIBRARY

      Part of Windows system, providing basic mechanisms to support COM, it
       provides:
           o Connections between components
           o Mechanisms to make IUnknown calls across processes
           o Underlying mechanisms for launching components

COMPONENT OBJECT SERVERS

      Is a body of code implementing a component object's services (methods and
       functions)
      Uses server code to create component object instances and in turn the object
       instance provides the services to the component object client

9. OBJECT LINKING AND EMBEDDING
      Mechanism to allow users to create compound documents
      Object = any set of data from one application treated as a unit
      Compound documents = documents that can contain objects created and
       maintained by multiple applications
      Embedding = just like pasting, gives the client a complete and independent copy
       of the data, but an object remembers its origin and can be edited
      When a document contains all the data for an object the object is embedded
      When a document contains only a reference pointing to data in another document
       the object is linked
      OLE is composed of a group of interrelated concepts, they are:

Linking and                Two methods of storing items created by external
embedding:                  server applications within an OLE document




                                                                                                17
In-Place                Occurs when en embedded item is activated in the
activation:              context of the container document

Automation:             Mechanism to allow one application to drive
                         another
                        Driving application = automation client / automation
                         controller
                        Driven application = automation server /
                         automation component

Compound File:          Provides a standard file format that allows
                         compound documents to be stored as structures,
                         providing internal support for the formats required
                         by different components

Uniform Data            Provides a set of interfaces allowing data to be
Transfer (UDT):          exchanged between OLE client and server
                         applications in a standard fashion

Drag and Drop:          Mechanism used to transfer data between
                         applications, etc.

Component               Provides infrastructure used by OLE objects for
Object Model             communication
(COM):




OLE STRUCTURED STORAGE

OLE Structured Storage is an OLE supported technology for storing and maintaining files
composed of
two or more OLE elements from different sources in a single document file and
involves three elements:




                                                                                          18
1. Compound              OLE supported structured storage implementations
File:                     and supports IStorage, IStream and ILockBytes
                          interfaces
                         Is any document containing linked and/or
                          embedded objects in addition to the document's
                          native data
                         Advantages:
                               o Incremental File Access – Individual object
                                   within the compound file can be accessed
                                   without loading the entire file
                               o File Access Modes:
                                        Transacted – Keeps both old and
                                            new copies of a document until
                                            instructed to save or undo the
                                            changes
                                        Direct – Makes immediate
                                            changes to the document, without
                                            ability to later undo the changes
                         Disadvantages:
                               o Size and performance
                               o Fragmentation

2. Storage               A COM object implementing the IStorage interface
Object:
3. Stream Object:        A COM object implementing the IStream interface
                          and is analogous to a file in a directory/file system




10. ACTIVEX CONTROLS
Comprises a group of technologies to allow developers to create Internet
applications using familiar tools and technologies.

Parts of the             Active Scripts
ActiveX family:          ActiveX Controls
                         ActiveX Documents
                         ActiveX Server framework
                         Code download and verification
                         HTML Extensions
                         Internet ActiveX Controls
                         Internet data download services




                                                                                  19
Foundation of             COM – Every ActiveX control is a COM object
creating ActiveX           exposing the IUnknown interface
controls consist          Compound Documents – Any document that
of eight elements:         includes linked or embedded objects and it's own
                           native data
                          Connectable Objects – Allows the control to
                           communicate with a client object by making use of
                           incoming and outgoing interfaces
                          OLE Automation – Permit access to the control's
                           interface through the client supplied programming
                           language to users
                          Persistence storage – ActiveX controls can
                           implement different persistence interfaces to save
                           a control's state
                          Property Pages – Displays internal properties of an
                           control in a tabbed dialog box
                          Uniform data transfer – Model for exchanging data
                           through the clipboard, drag-and-drop or automation
                          System-provided font and image objects – ActiveX
                           controls can use system - supplied fonts and
                           pictures to enhance visual appearance




11. GENERAL APPLICATION ARCHITECTURE
Services design model defines three services:

1. User Services deals with                 Receiving data input from users
interaction between the user and            Packaging user input for further
the application and consists out of          use
the following tasks:                        Data formatting
                                            Reporting
                                            Managing user preferences

2. Data Services interact with actual       Retrieving data and building
data source. Its four functional             result sets
areas are:                                  Inserting Data
                                            Updating Data
                                            Deleting Data

3. Business Services is the physical        Business rule
process of getting the client to talk       Data validation
to the server and may include any           Data access logic
of the following tasks:                     System administration logic
                                            Transaction support




Practice making use of Microsoft Transaction Server (MTS) and Microsoft
System Management Server (SMS). Know how to implement and configure them.



                                                                                 20
12. DEFINING COMPONENTS

CLASSES:         Provides basis for all objects and is the code that
                  defines the behaviours and attributes of the class
                 Nothing more than a collection of code that forms a
                  template for the creation of objects in an application
                 Represents a physical object

OBJECTS:         Is the implementation of a class.
                 When the code in a class is invoked, an object is
                  created.
                 Every object has an interface:
                       o Interface = publicly exposed method,
                           property or function a developer can use to
                           manipulate an object.
                 Every object must support four basic attributes
                  according to the object-oriented programming
                  theory:
                       o Abstraction:
                                Ability to provide a virtual
                                   representation of a physical object
                                   or process.
                                Using the concept of abstraction
                                   you can reference an object without
                                   needing to describe in detail every
                                   individual attribute of the object.
                       o Encapsulation:
                                Ability of a class to hide its inner
                                   workings from the application that is
                                   implementing it. e.g., Black box.
                       o Inheritance:
                                Ability to pass changes made to
                                   attributes and behaviours of parent
                                   classes to the subclasses whose
                                   foundation they provide. e.g.,
                                   Mother/Father => Son/Daughter
                                   inherits their looks.
                       o Polymorphism:
                                Many forms – Ability to implement
                                   interfaces generically in your
                                   applications without regard to the
                                   code in the class that implements
                                   the interface.
                                You can have multiple classes that
                                   define the same interface, but the
                                   actual code behind the interfaces
                                   may perform different tasks
                                   depending on the class used. The
                                   application that calls the class
                                   object will not care, as long as the
                                   interface remains constant.

COMPONENTS:      Is a compiled piece of code based on the




                                                                           21
                   aggregation of many classes

COLLECTIONS:      Represents groups of like / the same type of objects
                  Membership of the objects is not fixed – The
                   developer can add and remove objects from the
                   interface as needed




                                                                          22

								
To top