1 / 39

MODULE 4 CHAPTER 10 PROCESS OVERVIEW

MODULE 4 CHAPTER 10 PROCESS OVERVIEW A Software development process provides a basis for the organized production of software using a collection of predefined techniques and notations. 10.1 DEVELOPMENT STAGES

bien
Download Presentation

MODULE 4 CHAPTER 10 PROCESS OVERVIEW

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. MODULE 4 CHAPTER 10 PROCESS OVERVIEW A Software development process provides a basis for the organized production of software using a collection of predefined techniques and notations

  2. 10.1 DEVELOPMENT STAGES • 1.System Conception :– Conceive an application and formulate tentative requirements • 2.Analysis : – Deeply understand the requirements by constructing models • 3. System design : – Devise the architecture • 4. Class design : – Determine the algorithms for realizing the operations • 5. Implementation : – Translate the design into programming code and database structures • 6. Testing – Ensure that the application is suitable for actual use and actually satisfies requirements • 7. Training – Help users master the new application • 8. Deployment – Place the application in the field and gracefully cut over from legacy application • 9. Maintenance – Preserve the long term viability of the application

  3. 10.1.1 System Conception • Analysis • To specify what must be done. • Domain analysis focuses on real-world things whose semantics the application captures. • Application analysis addresses the computer aspects of the application that are visible to users. • System Design • Devise a high-level strategy — the architecture — for solving the application problem. • The choice of architecture is based on the requirements as well as past experience. • Class Design • To emphasis from application concepts toward computer concepts. • To choose algorithms to implement major system functions.

  4. 10.2 DEVELOPMENT LIFE CYCLES • 10.2.1 WATER FALL DEVELOPMENT • The stages in a rigid linear sequence with no backtracking. • Suitable for well-understood applications with predictable outputs from analysis and • design. • A water fall approach also does not deliver a useful system until completion

  5. Iterative Development • It is more flexible • First develop the nucleus of a system, then grow the scope of the system… • There are multiple iterations as the system evolves to the final deliverable. • Each iteration includes a full complement of stages: • Can accurately gauge progress and make adjustments to your plans based on feed back from the early iterations. • If there is a problem , you can move backward to an earlier stage for rework • – analysis, design, implementation, and testing.

  6. CHAPTER 11 • SYSTEM CONCEPTION • SYSTEM CONCEPTION • System conception deals with the genesis of an application. • Purpose of System Conception is to defer the details and understand the big • picture…...what need does the proposed system meet, can it be developed at a reasonable • cost, and will the demand for the result justify the cost of building it..?

  7. 11.1 DEVISING A SYSTEM CONCEPT • New functionality • Streamlining • Simplification automate manual process • Integration • Analogies • Globalization

  8. 11.1 DEVISING A SYSTEM CONCEPT. • Most ideas for a new system are extension of existing ideas. • Eg: HR dept may have a DB of employee benefit choices and require that a clerk enter changes. • An obvious extension is to allow employees to view and enter their own changes. • Many issues :( Security, reliability, privacy ...) • But.. New idea is a straightforward extension of an existing concept. • Eg2: online auction system. which is the automation of the existing system which is running presently manually .

  9. SOME WAYS TO FIND NEW SYSTEM CONCEPTS: • New Functionality- Add functionality to an existing system. • Streamlining- remove restriction or generalize the way a system works. • • Simplification- Let ordinary persons perform tasks previously assigned to specialists. • Automation- automate manual processes • Integration- Combine functionality from different systems. • Analogies- Look for analogies in other problem domains and see if they have useful ideas. • Globalization-Travel to other countries and observe their cultural and business • practices.

  10. 11.2 ELABORATING A CONCEPT A good system concept must answer the following questions. • Who is the application for ? • What problems will it Solve? • Where will it be used ? • When is it needed? • Why is it needed ? • How will it work

  11. Who is the application for? • • Understand the stakeholders of the system; • • Usually two important ones are: • Financial sponsor (client) • End Users. • What problem will it solve? • Bound the size of the efforts and scope of system • Determine what feature’s in and what features out • Where will it be used? • Compliment the existing base, locally, distributed, customer base • When is it needed? • – Feasible time, required time • Feasible time : The time in which the system can be developed within the constraints of cost and available resources • Required time : When the system is needed to meet business goals

  12. Why is it needed? • – Business case • How will it work? • – Brainstorm the feasibility of the problem • Investigate feasibility of the problem • Build prototype , if it helps clarfying a concept or removal a technological risk

  13. CASE STUDY • ATM Case Study (Automated Teller machine) • System Concept for an automated teller machine. • “Develop software so that customers can access a bank’s computer and carry out their own financial transactions without the mediation of a bank employee”

  14. • Who is the application for? The Vendor building the software (assume its we) • What problems will it Solve? ATM is built to serve both the bank (automation) and the customer (ubiquitous) • Where will it be used ? ATM are available at many stores, sporting events and other locations throughout the world • When is it needed? From an economic perspective, it is desirable to minimize the investment, maximize the revenue, and realize revenue as soon as possible. (OOMD Helps) • Why is it needed ? A novel product could outflank competitors and lead to premium pricing. Here the case study is taken for explanation. • How will it work? We adopt a three-tier architecture

  15. 11. 3. Preparing a Problem Statement Requirements Statement • Problem scope • What is needed • Application context • Assumptions • Performance needs Design • General approach • Algorithms • Data structures • Architecture • Optimizations • Capacity planning Implementation • Platforms • Hardware specs • Software libraries • Interface standards

  16. Throughout development, you should distinguish among requirements, design, and implementation. • Do not Make early design and implementation decisions or you will compromise development? • Most problem statements are ambiguous, incomplete, or even inconsistent. • Some requirements are just plain wrong. • …..The purpose of Analysis is to fully understand the problem and its implications

  17. CHAPTER 12 DOMAIN ANALYSIS 12.1 OVERVIEW OF ANALYSIS The problem statement should not be taken as immutable, but rather as a basis for refining the requirements. Analysis is divided into two sub stages Domain analysis Application analysis

  18. DOMAIN CLASS MODEL • First step in analyzing the requirements is to construct a domain model. • Static structure of the real world system is captured. • The domain model describes real-world classes and their relationships to each other. • Information for the domain model comes from the problem statement, artifacts from related systems, expert knowledge of the application domain and general knowledge of the real world.

  19. The steps to be performed to construct a domain class model: • Find Classes. • Prepare a data dictionary. • Find associations. • Find attributes of objects and links. • Organize and simplify classes using inheritance. • Verify that access paths exist for likely queries. • Iterate and refine the model. • Reconsider the level of abstraction. • Group classes into packages

  20. Finding classes • Classes often correspond to nouns. Ref figure 12.2. • Eg- ” a reservation system sell tickets to performances at various theater”-Tentative classes would be Reservation, System, Tickets, Performance and Theaters. • Idea is to capture concepts. not all nouns are concepts, and concepts are also expressed in other parts of speech.

  21. For the Case study of the ATM: The following are the classes extracted from problem statement nouns. Figure 12.3

  22. Additional classes that do not appear directly in the statement but can be identified from our knowledge of the problem domain

  23. • Domain Class Model: Keeping the right classes Discard unnecessary and incorrect classes according to the following criteria • Redundant classes: If two classes express the same concept, you should keep the most descriptive name. ATM example. Customer and user are redundant; we retain customer because it is more descriptive. • Irrelevant classes Apportioning cost is outside the scope of the ATM software. • Vague classes: class should be specific.

  24. Attributes: Names that primarily describe individual objects should be restated as attributes. • Operations: If a name describes an operation that is applied to objects and not manipulated in its own right, then it is not a class. Eg-if we are simply building telephones, then call is part of the state model and not a class • Roles: The name of a class should reflect its intrinsic nature and not a role that it plays in an association. • Owner of a car..i n a car manufacturing database, not correct as a class. It can be a person( owner, driver, lessee) Implementation Constructs: Eliminate constructs from the analysis model that are extraneous to the real world. We may need them during design and not now. • Derived classes: As a general rule, omit classes that can be derived from other classes. mark all derived classes with a preceding slash(‘/’)in the class name.

  25. Preparing a Data Dictionary • Prepare a data dictionary for all modeling elements. • Describe the scope of the class within the current problem, including all assumptions or restrictions on its use. • DD also describes associations, attributes, operations and enumeration values Data Dictionary for the ATM classes Account ATM Bank BankComputer CashCard Cashier cashierStationCentralComputer Consortium Customer Transaction Finding associations • A structural relationship between two or more classes is an association. • A reference from one class to another is an association. • Associations often correspond to verbs or verb phrases. • Idea here is to capture relationships

  26. Keeping the Right Association Discard unnecessary associations, using the following criteria: • Associations between eliminated classes. • Irrelevant or implementation associations. • Actions: An association should describe a structural property of the application domain not a transient event. • Ternary associations. • Derived associations :they may be redundant Further specify the semantics of associations as follows: • Misnamed associations. • Association end names. • Qualified associations. • Multiplicity • Missing associations • Aggregation.

  27. Fig 12.9 shows class diagram with remaining associations

  28. Find attributes of objects and links. • Attributes are data properties of objects • Attribute values should not be objects; use an association to show any relationship between objects. • Attributes usually correspond to nouns followed by possessive phrases, such as “the color of the car Keeping the right attributes: Eliminate unnecessary and incorrect attributed with the following criteria: • Objects . Discordant attributes • Qualifiers . Boolean attributes. • Names • Identifiers • Attributes on associations • Internal values • Fine detail

  29. Refining With Inheritance Organize classes by using inheritance to share common features: • Bottom up generalization. • Top-down generalization • Generalization vs. enumeration. • Multiple inheritance • Similar associations • Adjusting the inheritance level. • Fig 12.11 shows the ATM class model after adding inheritance

  30. • Verify that access paths exist for likely queries. Trace access paths through the class model to see if they yield sensible results. Iterate and refine the model. A class model is rarely correct after a single pass, so iterate and refine the model. • Fig 12.12 shows a revised class diagram that is simpler and cleaner.

  31. • Reconsider the level of abstraction. Abstraction makes a model more complex but can increase flexibility and reduce the number of classes.

  32. 3. Domain State Model The Following steps are performed in constructing a domain state model • Identifying classes with states • Finding states • Finding Events • Building state diagrams • Evaluating state diagrams After running thro the above steps, the domain state model obtained is a shown in Figure 12.14

  33. 4. Domain Interaction Model • The Interaction model is seldom important for domain analysis. • The Interaction model is an important aspect of application modeling 5. Iterating the Analysis The iteration to the analysis should ne done as follows: • Refining the Analysis Model • Restating the Requirements • Analysis and Design.

More Related