MEETING USE CASE SCENARIOS

(Which technologies are appropriate for implementation of a given business solution?)

ELECTRONIC DATA INTERCHANGE (EDI)	Method of transferring structured data between two computers by electronic means
THE INTERNET	Consider OSI (open System Interconnection) standards Defines networking framework by implementing seven layers of protocol (Physical, Data, Network, Transport, Session, Presentation, Application) Handy Acronym: "Paula Did Networking Till She Passed Away"
POSIX (PORTABLE OPERATING SYSTEM INTERFACE FOR UNIX)	Set of IEEE and ISO standards defining an interface between programs and operating systems
SOLUTIONS IN USE CASE SCENARIOS	Enterprise Solutions Spread across entire scope of a business enterprise Distributed Solutions N-Tier Architecture – different components perform different parts of a task Centralized Solutions Stand alone applications where minimal shared information is required Collaborative Solutions Involves multiple software/hardware packages that must function interactively

 

CHOOSING DATA STORAGE ARCHITECTURE

• Consider
  

  • Amount of users accessing at same time
    

  • Storage capacity
    

  • Transactions / minute
    

  • Database Growth
    

  • Available security features
    

  • 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
  

  • Business requirements
    

  • Use case scenarios
    

  • Existing technology constraints
    

  • Impact of shortfalls

   

CONCEPTUAL AND LOGICAL DESIGN

• Every solution design must be evaluated in terms of
  

  • Availability
    

  • Extensibility
    

  • Maintainability
    

  • Performance
    

  • Scalability
    

  • Security

   

DEVELOP AN APPROPRIATE EDPLOYMENT STRATEGY

1. Break down application in series of phases/versions
   

2. Plan test environment for each test phase
   

3. After testing plan a test rollout – Dry run of how you will implement product
   

4. Execute the test rollout
   

5. Deploy this phase to the production environment
   

6. Collect and analyze bug reports
   

7. Fix Bugs
   

8. 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

Types of DBMS Methodologies

Flat-File

1. e.g. Telephone directory
   

2. Data is stored in one large file
   

3. Relies on standard file I/O processes
   

4. Contains only one record structure
   

5. Uses no links between separate records
   

6. Relatively fast
   

7. Can become very big and hold redundant data
   

Customer Data

Discount Terms

Order Record

Shipping Data

Accounts Payable

Hierarchical Database

1. Single flat file is replaced with series of tables linked in a structured relationship
   

2. Child record can be linked to only one parent
   

3. Link between a child and parent record is permanent
   

4. Child records can only be reached through a parent record

 

Relational Database

1. Stores data in one or more tables which can be linked to any other table
   

2. Consists of Entities (Tables), Fields (Columns) and Records (Rows)

 

 

Types of DBMS Methodologies

1. Analysing the relational data structure of a database use ERA
   

2. 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
        

      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
Rules of Normalization = Normal Forms:	First Normal Form No repeating groups. Data in rows and columns must contain only one value Every record in the table must be unique and no duplicates are permitted PK must satisfy several conditions No duplicates Can not contain Null values Every record must have a PK All data must be non decomposable – the data can not be broken down into simpler pieces Second Normal Form Every field in a table must relate to its PK field in its entirety Third Normal Form 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 integrity

Guarantees the logical consistency of the database by ensuring the values for PK and FK pointing to PK are always in agreement Three rules that can be imposed when updating PK: Restrict – Delete / Update on PK not allowed Cascade – Any change to PK is automatically applied to all FK 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?

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 correct controls	TabStrips Tool, Progress & StatusBars Tree and ListViews Sliders, text boxes, labels, etc.
Using MDI's / SDI's
Adding Shell extensions	File Object – Any item within the shell, e.g. Printers 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 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 Will you use Console Applications? e.g., TSR utilities Terminal emulators Hardware configuration utilities Accessibility – Visual/hearing impaired or spelling impaired consideration for users Deployment Platform Consider 32 Bit Windows or 16 Bit Windows Internet or Intranet, Browser compatibility, etc. must be kept in mind User assistance: Fully indexed and searchable help topics Context-sensitive help – pressing F1 "What's this" Help, ToolTips, Status Bars Task Help (The assistant in MS Word for example)

 

5. DERIVING THE LOGICAL & PHYSICAL DESIGN

1. Logical design = Theory and planning behind the design and implementation (Physical Design)
   

2. Logical design is concerned with behaviour from an abstract perspective
   

3. Physical Design is concerned with the actual implementation of the design
   

4. Logical design is independent of technology constraints
   

5. Physical design must consider system hardware and software where the interface will be employed

 

DERIVING THE LOGICAL/CONCEPTUAL DESIGN

1. Requires that you begin with a structured base and evolve a solution that will provide a physical implementation satisfying business requirements
   

2. 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 Model	Describes the process your application supports rather than the process your application performs To generate the model Think of each Input an Output point in your context model as a client of your application. Consider the business tasks that each client must perform Eliminate tasks that are not the responsibility of your application Determine the sequence in which each task is performed
3. Task-Sequence Model	Describes internal flow of operation inside the 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 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 Decision points(Diamonds), contains a question with all possible answers Connections(Arrows between action and decision points), direction of arrow shows sequence of the elements

 

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

 

1. Identifying business objects and services	The primary components for constructing a logical design
2. Interface design	An interface is a statement defining the elements required to call a service, along with any preconditions along with the service
3. Business object interdependencies	Dependencies between business objects appear when one business object calls for a service supplied by another business object Must be avoided at all times
4. Employing usage scenarios to validate logical design	Usage Scenarios ensure that requirements in the conceptual view is fully and correctly expressed Ensures clarity and correctness of the design
5. Design Revisions	Producing a complete logical design does not happen in one step Begin by creating an initial design, then criticise and dissect it, refining the design and adding detail

 

1. Logical Design Risk Factors to Consider
   

   • Behaviour of the logical design does not match usage scenarios
     

   • Logical design must be co-ordinated with the enterprise architecture (Hardware/software)
     

   • Must not depend on external systems
     
     

2. Baselining the Logical Design
   

   • Tests performed before making any changes to a system
     

   • Key requirement of baselining a logical design is validating the usage scenarios
     
     

3. Asses the potential impact of the logical design by considering
   

   • Performance
     

   • Maintainability
     

   • Extensibility
     

   • Scalability
     

   • Availability
     

   • Security

    

DERIVING THE PHYSICAL DESIGN

1. Means translating the logical design into a cost effective solution
   

2. Roles filled by teams in a physical design
   

   • Product Management – Governs the physical design process
     

   • Development – Creates the design
     

   • QA/Testing – Plans test process
     

   • Logistics – Plans appropriate distribution
     

   • User Education – Plans training programs
     

3. Assessing the impact of the design, consider
   

   • Performance
     

   • Maintainability - considering:
     

     • Good three tier design
       

     • Designing for change
       

     • Business rules
       

     • Code readability
       

   • Extensibility – How new functionality can be added to the system with minimum cost and time impact
     

   • 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
       

   • 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
       

   • Security
     

4. Physical design as a process: The process of turning a logical design into a physical solution and involves a sequence of events
   

   • Allocating services to components
     

   • Distributing components across the network
     

   • Refine component packaging and distribution
     

   • Define component interfaces as a mechanism for implementing the service relationship between components
     

   • Determine physical media storage, how data will be accessed and distribution of physical data
     

   • 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 Envisioning – Vision statement provides product/service goals Planning – Defines customer expectations Developing – Establish series of interim milestones, debugging, testing, etc. Stabilisation – Rigid operational requirements for thorough testing
3. Development /Application Model	Designing for flexibility
4. Solutions Design Model	Aids developers in anticipating user requirements Aligns solution development with business goals
5. Enterprise Architecture Model	Provides structures for business integration Consider Application Architecture – standard interfaces, services, etc. Business Architecture – Describes how business enterprise operates Information Architecture – What information is needed by the organisation in order to run the business operations Technology Architecture
6. Infrastructure Model	Guides system developers in system deployment
7. Total Cost of Ownership Model	Methods to identify costs in technology investments Aimed at improving return on investment Consider Role of value Cost discrepancies Business enterprise requirements

 

7. DEPLOYMENT ISSUES

1. Method of distributing your application
   

2. Deployment Medium