1 / 17

Software Lifecycle

Software Lifecycle. A series of steps through which a software product progresses Lifetimes vary from days to months to years Consists of people overall process intermediate “products” stages of the process note the reality of feedback loops, the stages of the process are not discrete.

raubry
Download Presentation

Software Lifecycle

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. Software Lifecycle • A series of steps through which a software product progresses • Lifetimes vary from days to months to years • Consists of • people • overall process • intermediate “products” • stages of the process • note the reality of feedback loops, the stages of the process are not discrete

  2. Phases of a Software Lifecycle • Standard Phases • Requirements Analysis & Specification • Design • Implementation and Integration • Operation and Maintenance • Change in Requirements • Testing throughout! • Phases promotes manageability and provides organization

  3. Background - Objects • Traditionally, programming has been“procedure-oriented” • Focus on process, algorithms, and tools • A system’s data has secondary importance • Data and process considered separate • The data is external to a program; a program reads it in, manipulates it, and then writes it out • Relationships between data types not considered important • As a result, similarities were not leveraged leading to duplication of code

  4. Background, continued • Problems • Lack of data encapsulation • changes to a data format typically required major rewrites • Poor models • “Real world entities” not well represented in requirements, design and implementation • If an assumption about an entity changes, multiple modules may have to change in response (since logic about an entity may be spread across modules) • this could be blamed on the poor abstraction of the structures and ADT’s used on common programming languages some years ago

  5. Low reuse • Procedure-oriented modules are often difficult to reuse outside of their original development context • Ever written in a procedure-oriented language? • global variables everywhere - awful messes can occur

  6. Object-Oriented Programming • Objects combine both data and process • Increases the stature of data to be equivalent to process • Focus on “real-world entities” • Objects often represent real-world counterparts: people, countries, calendars, cars, organizations, etc. • this allows for better abstraction of our programming entities to the corresponding real entities contained in the problem space in the real world.

  7. Enables Categorization • Objects with high levels of abstraction can often be specialized to more specific categories • For instance, car Honda Civic • or person athlete soccer player • We get “inheritance” and “polymorphism” from this • polymorphism will be methods with the same name that perform different tasks (see KW text)

  8. Object-Oriented Programming, continued • Addresses “Procedure-Oriented” Problems • Data and Process encapsulation • Encapsulates data and related algorithms behind a single interface; both can be evolved without affecting other objects or modules (as long as the interface is constant) • recall ADT’s (Parnas) • Natural Models • Objects can be used to appropriately structure a design or accurately create a set of requirements based on knowledge about the real-world counterpart • but consider Jackson’s criticisms • Increased Reuse • Well-designed object is often independent of the original development context

  9. Method 1 Method 2 Method 3 Objects • Data and operations are defined as a single unit • Object := • encapsulated state (attributes) • methods that exclusively control access to the state Object name access to attributes state (attributes)

  10. Classes • Each object is an instance of a class • A class serves as a blueprint • It defines the attributes and methods for the class • Thus, each object of a class has exactly the same interface and set of attributes • each object can have different values for its attributes Professor (Professor) (Professor) Name: string Dept: string Jean Raoul French Debra Richardson ICS get_name() return string .... get_name() .... get_name() .... class Professor Object instances of Professor

  11. Object Model Notation: Introduction Class Name Classes are represented as rectangles; The class name is at the top, followed by attributes (instance variables) and methods (operations) Depending on context some information can be hidden such as types or method arguments InstanceVariable1 InstanceVariable2: type Method1() Method2(arguments) return type Objects are represented as rounded rectangles; The object’s name is its classname surrounded by parentheses Instance variables can display the values that they have been assigned; pointer types will often point (not shown) to the object being referenced (Class Name) InstanceVariable1 = value InstanceVariable2: type Method1() Method2(arguments) return type

  12. Object Communication • Objects communicate via method invocation • This is known as message passing • Legal messages are defined by the object’s interface • This interface is the only legal way to access another object’s state (Rectangle) Object get_width width height get_height calculate_area

  13. Objects: Terminology • Class • set of objects having the same methods and attributes • has a specification and an implementation • behavior is defined by the operations that can be performed on objects belonging to the class • Method • action that can be performed on any member of a class • Encapsulation • packaging the specification and implementation of a class so that the specification is visible and the implementation is hidden from clients • Instantiation • the creation of a new object belonging to a class

  14. YOUR development process and its documentation • Review your text section 1.5. • Specify the problem requirements (what is needed?) • analyze to identify the problem inputs and outputs • identify constraints on system • identify processes to transform the inputs to outputs

  15. Design the classes to solve the problem • 3 possibilities • locate reusable classes in libraries to use • modify existing classes to make them reusable • design new classes where necessary • usually involves a worker class to represent the object to be modeled, and • a user interface class or an application class to interact with the user

  16. Implementation • write out the classes, implement the algorithm

  17. Test and Verify the classes • this can become a big deal • Maintain and update when needed

More Related