Santosh 的个人资料Santosh Kumar照片日志列表更多 工具 帮助

日志


Structured System Analysis and Design

- SSAD
+--- Definition of a System
|  +--- A group of Interacting elements that constitutes a whole
|  +--- An organised set of units which produces the optimum results
+--- Characteristics of a System
|  +--- Organisation
|  +--- Interdependance
|  +--- Interaction with environment
|  +--- Central Objectives
+--- Parts of a System
|  +--- Elements/Units
|  +--- Input
|  +--- Output
+--- Categories of a System
|  +--- Closed/Stable System
|  +--- Open/Adaptable System
|  +--- Information System
|     +--- It's contineous
|     +--- Designed as per user's request
|     +--- Output given to the user for further verification
|     +--- Categories
|        +--- Transaction Processing System {Low Level}
|        +--- Management Information System {Mid Level}
|        +--- Decision Support System {Top Level}
+--- Development Techniques of a System
   +--- System Development Life Cycle {SDLC}
   |  +--- It contains several phases in development cycle
   |  +--- Also a sequencial forwarding
   |  +--- Can jump back at any stage
   |  +--- Phases of SDLC
   |     +--- Preliminary Investigations
   |     |  +--- It's a verification of user's request
   |     |  +--- Clarity of the requirement is confirmed
   |     |  +--- Most urgent requirements are picked first
   |     +--- Information Gathering
   |     |  +--- Interview
   |     |  +--- Questionnaire
   |     |  +--- Record Inspection
   |     |  +--- Observation
   |     +--- Feasibility Study
   |     |  +--- Technical
   |     |  +--- Financial
   |     |  +--- Operational
   |     +--- System Analysis
   |     +--- System Design
   |     |  +--- Methodology
   |     |  |  +--- Structured Design
   |     |  |  +--- Form Driven Design
   |     |  +--- Parts
   |     |     +--- Input Design
   |     |     +--- Output Design
   |     |     |  +--- Information Report
   |     |     |  +--- Summary Report
   |     |     |  +--- Exception Report
   |     |     |  +--- Turnaround Document {Acts as an input}
   |     |     +--- File/Database Design
   |     |        +--- Storage and Retrival
   |     |        |  +--- Normalisation
   |     |        |  +--- Denormalisation
   |     |        +--- Table Design
   |     |           +--- Master File
   |     |           |  +--- Static
   |     |           |  +--- Dynamic
   |     |           +--- Transaction File
   |     |           +--- Work File {temp file}
   |     |           +--- Audit File {tracking file}
   |     +--- Coding
   |     +--- Testing
   |     |  +--- Alpha testing
   |     |  +--- Beta testing
   |     |  +--- Unit testing
   |     |  +--- Integraded testing
   |     +--- Integration
   |     +--- Implementation
   |     |  +--- Direct Implementation {NEW=>}
   |     |  +--- Parallel Implementation {NEW=> OLD=>}
   |     |  +--- Pilot Implementation {ONE SECTION OF AN ORGANISATION}
   |     |  +--- Phase Implementation {ONE SECTION OF A PROGRAM}
   |     +--- Evaluation
   +--- System Analysis Development {SAD}
   |  +--- System is devided into several component
   |  +--- Each is analised indivisually
   |  +--- Analysis and Documentation tools
   |     +--- Decision Table
   |     |  +--- [11] Condition Stub [Options]
   |     |  +--- [12] Condition Entry [Y/N]
   |     |  +--- [21] Action Stub [Clauses]
   |     |  +--- [22] Action Entry [X]
   |     +--- Decision Tree
   |     +--- Structured English
   |        +--- An English like language use to describe the logic
   |        +--- Types are
   |           +--- Sequential
   |           +--- Selection
   |           +--- Iteration
   +--- System Prototype
      +--- A working model of a system
      +--- Required when users themselves do not know their requiremnet
      +--- Types
         +--- Data Modeling {Entity Relation Diagram}
         |  +--- It involves the data like input, stored, processed, produced
         |  +--- Used for data handling and its relationship
         |  +--- Components are
         |     +--- Entity
         |     |  +--- Person
         |     |  +--- Car
         |     +--- Attributes
         |     |  +--- Person
         |     |  |  +--- Name
         |     |  |  +--- Age
         |     |  |  +--- Address
         |     |  +--- Car
         |     |  |  +--- Manufacturer
         |     |  |  +--- Model
         |     |  |  +--- Price
         |     +--- Relationship
         |        +--- One to One {Driver<==>License Student<==>Rollno}
         |        +--- One to Many {Student<==>Subjects Cutomer<==>Orders}
         |        +--- Many to Many {Student<==>Teacher Project<==>Employees}
         +--- Process Modeling {Data Flow Diagram}
            +--- Used to pictorially depict the entire processing
            +--- Traces data flow through different process with symbols
            +--- Components are
            |  +--- Entity
            |  +--- Process
            |  +--- Data store
            |  +--- Data Flow
            +--- Levels are
               +--- 1st level DFD {Only entities are shown}
               +--- 2nd level DFD {Entities and Process are shown}
               +--- 3rd level DFD {Entities, Process and Data Stores are shown}
 
»»»»»»»   by Santosh Kumar ? Original @ http://santu4you.spaces.live.com

Architectural Pattern for Software Engineering

 
Architectural patterns are software patterns that offer well-established solutions to architectural problems in software engineering. It gives description of the elements and relation type together with a set of constraints on how they may be used. An architectural pattern expresses a fundamental structural organization schema for a software system, which consists of subsystems, their responsibilities and interrelations. In comparison to design patterns, architectural patterns are larger in scale.
 
Even though an architectural pattern conveys an image of a system, it is not an architecture as such. An architectural pattern is rather a concept that captures essential elements of a software architecture. Countless different architectures may implement the same pattern and thereby share the same characteristics. Furthermore, patterns are often defined as something "strictly described and commonly available". For example, layered architecture is a call-and-return style, when it defines an overall style to interact. When it is strictly described and commonly available, it is a pattern.
 
One of the most important aspects of architectural patterns is that they embody different quality attributes. For example, some patterns represent solutions to performance problems and others can be used successfully in high-availability systems. In the early design phase, a software architect makes a choice of which architectural pattern(s) best provide the system's desired qualities.
 
Examples of architectural patterns include the following:
 
 • Layers
 • Presentation-abstraction-control
 • Three-tier
 • Pipeline
 • Implicit invocation
 • Blackboard system
 • Peer-to-peer
 • Service-oriented architecture
 • Naked objects
 • Model-View-Controller
 
SOA: A service-oriented architecture can be defined as a group of services, which communicate with each other. The process of communication involves either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed.
 
Ref: http://en.wikipedia.org/wiki/Architectural_pattern_%28computer_science%29