1 / 30

Najmul Ikram Qazi

CSC447-Enterprise Systems Development Pre-requisites: Database Systems, Object-Oriented Programming. Najmul Ikram Qazi. Objectives.

maia-dorsey
Download Presentation

Najmul Ikram Qazi

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CSC447-Enterprise Systems DevelopmentPre-requisites: Database Systems, Object-Oriented Programming NajmulIkramQazi

  2. Objectives • The course has been designed to enable you to understand what enterprise systems are, and how they are developed. The course aims to make you understand the principles, techniques and tools that are required to develop enterprise systems.

  3. Object Oriented Analysis and Design • Something more than object-oriented programming • Object-orientation from the very start • Based on real life objects • Gives long term benefits • However, it is not a magic of solving problems

  4. Object Oriented Analysis and Design • Classes and objects • Inheriting from a class • Abstraction • Encapsulation • Association between classes • Generalization, specialization

  5. Object Oriented Analysis and Design • What is a use case? • Identifying objects from requirements • Objects from nouns • Examples: Student, teacher, course, lecture, attendance • UML

  6. Requirements Management: Problems • Demand for new features at later stages • Deadline too short to fulfill requirements • Budget too short to fulfill requirements • Unstructured development • Users not clear about their requirements • Users not able to convey their requirements • Rigid process

  7. Requirements Management: Solution to the Problems • Solution varies from case to case • Can we refuse? Can we simply agree? • One solution: ask for additional cost • In-house development: ask for additional time • Incremental development • Prototypes

  8. Diversity of Software Projects, Strategies • Product vs. project-based development • Small vs. large projects • Diversity of domains • New technology factor • Experienced vs. inexperienced team • Can we freeze requirements?

  9. Gathering Requirements • Meetings with the user • Study existing documents • Existing forms • Observe the overall workflow, processes • Brainstorming sessions • Study similar systems

  10. Characteristics of a Good SRS • Should be correct • Should not be ambiguous • Should be complete • Should be consistent • Should be categorized • Should be measurable • Should be achievable

  11. Component-Based Software Development • Reuse of existing code • Reduce development effort and cost • Reduce development time • Better design of overall system • Modular design (not a new concept) • Use of third party components • Each component can be tested independantly

  12. 3-Tier, N-Tier Architecture • Converting an old application to a Web application • Separation of user interface • Separation of data access • Business logic • Concept of layers • Modifying one layer without disturbing others • Effects on performance

  13. Aspects of Scale and Granularity • Units of abstraction • Units of analysis • Units of development • Units of compilation • Units of accounting • Units of deployment • Units of system management

  14. Some Concepts • Interoperability: How can two independent systems cooperate • Interface: Exposes the services of a component. It is a contract • State of a component: values of all member variables at some time instance • A lack of overall architecture in object-oriented systems has worse effects than the old procedural systems

  15. Events and Messages • Messages are independent of programming languages • May be in the form of XML • Event is similar to a procedure call except: • Target is not known to the source • Has multiple targets • Does not (normally) return a value

  16. Component Models and Platforms • XML: The biggest advantage of XML comes out when it is used as common language among applications of independent origins • RPC (Remote Procedure Call) • SOAP (Simple Object Access Protocol) • Accessing remote objects • Typically using HTTP • SOAP message, envelop • XML Web Services: services offered by Web servers, not for people, but for applications

  17. CORBA • CORBA: Common Object Request Broker Architecture • Used by many large enterprise systems as object bus • Facilitates distributed and collaborative computing • Developed by OMG (Object Management Group) • OMG: a non-profit organization for standardization and interoperability, also introduced UML, OMG IDL

  18. CORBA Services • Naming service • Trading service: facilitates to announce the services, search for services • Event service, notification service, concept of pulling information and pushing information • Object transaction service • Security service. Authenticating, Authorising

  19. CORBA Services • Concurrency control service, acquiring and releasing locks • Licensing service • Lifecycle service • Creation, deletion, copying of objects • No reference counting, no garbage collection • Object query service: querying the instances

  20. Microsoft COM • Concepts of interface, implementation, why separate them • Interface identified by a GUID • Reference counts • CLSID – a GUID • IDL

  21. Microsoft DCOM • Client-side proxy object • Server-side stub object • Communication across process boundaries, machine boundaries • Marshaling data to platform-independent format • Activex controls • MTS • MSMQ

  22. Microsoft COM+ • JIT activation • Transactions • Auto deactivation • Queuing

  23. Designing Data Model • Redundancy • Problems • Uses • Enhancing performance • Indexes • Denormalization • Foresee number of rows? • Create useful views • Data Warehousing

  24. Making Codes and IDs • Where to use free text, where to use code • Numeric Id with auto increment • GUID • Abbreviations • Date, time with numbers • Significant digits

  25. Designing Data Model • Normalization • Central Database? • Can all output reports be generated? Possibility for maximum future reports, statistics • Based on real life objects / entities • Searchable, analyzable, categorized • Integrity • Appropriate detail level, depth

  26. Structure of a Typical Large Database • Small tables for codes, categories, configurations, parameters • Tables for people: users, employees, clients • Tables for structures: departments, offices, programs • Tables for schedules • Transactions, parent detail tables • Tables for hierarchy

  27. Some Advanced Techniques • Tables for the system itself • Metadata: table for tables, fields, menu items • Additional fields in each table: creation date, created by, updation, confirmation, accessed by • Importance of flags, status fields • Change history, logs • Access rights

  28. Designing Reports • Use report generator? • Base query • Grouping • Sorting • Sums • Matrix reports, statistical reports, graphs • Selection of report parameters • Customization: run time, design time

  29. Designing User Interface • Importance of user interface • Power and efficiency of user • Simplicity • Use case driven • Consider user training level • Separate strategy for read-only users

  30. Designing for Quality • Designing for performance, scalability: performance cannot be ‘added’ later on • Designing for usability, configurability • Security, correctness are essential qualities • Reliability, availability • Internal qualities: flexibility, reusability, testability • Tradeoff

More Related