Lecture 2 CSCI-260-W02. Sample Class Agenda Last lecture review Homework discussion New material Homework assignment –Stay to the end of the class if. - презентация

1 Lecture 2 CSCI-260-W02

2 Sample Class Agenda Last lecture review Homework discussion New material Homework assignment –Stay to the end of the class if youd like to hear details –Will also be available on website in syllabus and class noteswebsite Questions –Instructor will pause after each segment –Alternatively, can be asked any time during the class Breaks –One 10-minute break approximately ~ 7:00 pm

3 1.1 Review Questions Why do we need s/w (software) engineering? What s/w cycle activities can you list?

4 Definitions Hirschheim, R., Klein, H. K., Lyytinen K., Information Systems Development and Data Modeling, Conceptual and Philosophical Foundations, Cambridge University Press, New York, 1995, p. 11 Systems development encompasses the complete range of activities involved in the process of building, including analysis, design, implementing and maintaining an IS –IS = information system Systems analysis – the process of collecting, organizing and analyzing facts about a particular IS and the environment in which it operates Systems design – the conception, generation and formation of a new system. Builds upon the understanding gained through systems analysis

5 1.1 Review Questions Why do we need s/w (software) engineering? What s/w cycle activities can you list? What was an original model of s/w life cycle? –What are the advantages of it? –What are the disadvantages?

6 Waterfall Life-Cycle Model Classical model where each stages documented output is fed into the next stage Pro Useful when the requirements are well-understood and unlikely to change Rare case in modern s/w development Con Inflexible partitioning into stages Heavy emphasis on documentation

7 Spiral Life- Cycle Model Pro Activities repeat in a spiral manner from original concept to its final form Useful for projects that dont conform to waterfall cycle Directly addresses major risks, i.e.: Creating unneeded product Including unnecessary functions, etc… Emphasizes continuous re-assessment and goals adjustment Con Too rigorous for short life span s/w

8 Too Much of Software Engineering?

9 Manifesto for Agile S/W Development Created on February 2001 (meeting of 17 agile method proponents) We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: –Individuals and interactions over processes and tools –Working software over comprehensive documentation –Customer collaboration over contract negotiation –Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.

10 The Agile (Lightweight) Methods More informal relaxed approach serving as an alternative to document-driven, heavy-weight s/w development methods Specific methods: –Heavy customer involvement in all stages of the project –Incremental delivery of the product –An openness to change in the specifications of the system Customer satisfaction is more important than conforming to the plans –Developers work in pairs in a supportive, collaborative manner 2 programmers work side-by-side at a single workstation is discovered by studies to have less code defects than individual works Pro –Useful for software project with: Short life span Quick development for pressing need Intended for rapidly changing environment –Stress on customer satisfaction –Increase morale of the development team Con –Lack of structure and limited testing can cause multiple operational errors (hence, customer dissatisfaction) unplanned time and cost overruns problems with maintenance (if needed)

11 Discussion on Agile Methods Interesting ideas and approaches?

12 Other Methods Prototyping – creates initial model with limited functions –Pro: useful for vague requirements, high investment costs, unknown usability or demand –Con: the prototype is often an unusable throw-away, adding to final costs Concurrent engineering – many activities occur at once –Pro: in theory promotes more co-operation and reduces risk, speeds up product delivery –Con: creates stressful environment full of uncertainties Real-time system development Creative program solving … P. S.: Each organization has its own model that may combine ideas from different approaches to best fits with its goals.

13 Life Cycle Model to Be Used in This Class A combination of: –Waterfall model –Spiral model –Agile methods Includes: –Limited but necessary documentation –Thorough verification of stated requirements Requirement being given in the textbook assignments are considered stable and mandatory See illustration on the next slide…

14 Simplified Software Development Process Analysis/Requirement Gathering –Understand the problem to solve –Communicate with non-technical customers (end users) –Convey gathered information in writing to technical audience Architecture (high-level, big picture) & Design (low-level, up to coding details) –Create an abstract representation of the system to be build –Make sure the software will meet reqs and can address future upgrades Coding –Transfer a design to computer code Testing & Verification –A process of eliminating mistakes (bugs) –Demonstrate correctness and fulfillment of stated reqs Delivery –Deliver and install the product, hand-off to the users, give training Maintenance –cope with newly discovered problems, changed environment or new reqs Analysis source code; user documentation yes Design Coding Testing bugs found? done; deliver to customer start no Requirement specification Design specification Test procedure; test reports Programmers Users For this class: Initial requirements are elicited and documented from the textbook Test procedure and test reports are combined in a single table No maintenance phase after delivery Test procedure; test reports

15 Some Goals of Quality Software (no matter what approach you use) 1.It works. 2.It can be modified without excessive time and effort. 3.It is reusable. 4.It is completed on time and within budget.

16 Goal 1: Quality Software Works Determine software requirements –What is to be provided by a computer system or software product, not how it is done Develop programs that meet requirements by fulfilling software specifications –Detailed description of: functions inputs processing outputs interfaces (including user interface (UI)) performance (response time, appearance), etc… –Provides specific info needed to design and implement the product The program works if it is: –complete– should do everything thats needed –correct – should do it right –usable – provide user interface easy to work with –efficient – complete in a reasonable time as appropriate for the task

17 S/W Requirement Specification Main parts: 1.Introduction 1.1 TOC, list of figures and tables, vocabulary and abbreviations defined 1.2Statement of Scope –Describes generically what this program is trying to do 1.3 Software Context –Where does this program fit into the big picture 2.Usage scenarios 2.1 User profiles –Who are the users (actors) 2.2Use cases 3.Requirements divided into groups: 3.1Functional (F) 3.2Data (D) 3.3Human User Interface (U) 3.4Hardware Interface (H) 3.5Performance (P) 3.6Testing (T) Hierarchically structured from more abstract to more precise –Traceability matrix Most important! Is used to validate written software against requirements Prepared with: –Specialized software (big-scale projects: DOORS, ReqPro, etc.) –Word, Excel, Access, etc. (small-scale) IMPORANT!!! This is a part of each homework (simplified) ! … F3. Display a text fragment F3.1 Make text font Bold F3.2 Make it to fit into a textbox F3.2.1 Make it size 10 F4. Print a textbox (see U5.2 – cross-link ) …

18 Traceability Matrix Structure Req. Num ber DescriptionType (Functional, Data, Testability, UI, Hardware, Secuirty, etc.) Source (Who reques- ted it?) Author (Who wrote it?) Date last edited Status Code: (Created; Approved; Written; Tested; Deferred; Rejected) Manda tory ot desira ble? Product sub- system Notes … F1Output text.FunctionProf Turiy 09/18/06TestedMClass Writer F1.1Output on the screen FunctionProf Turiy 09/18/06WrittenMMethod Writer.to Screen( ) F1.2Text should read: Hello World! FunctionProf Turiy 09/18/06RejectedDNo greeting required.

19 Why is Requirement Spec needed? How the customer explained it How the Project Leader understood it. How the Analyst designed it How the Programmer wrote it How the Business Consultant described it How the project was documented What operations installed How the Customer was billed How it was supported What the Customer really needed

20 The Unified Method An organized approach (methodology) is needed to implement models of reality –A collection of specific procedures for creating a system that meets users needs In several ideas were consolidated to create Unified Method methodology 3 key elements: 1.Use-case driven –Describe a sequence of actions performed by a user within the system to accomplish some task 2.Architecture-centric –Structured target system consisting of interacting components (not monolithic) 3.Iterative and incremental –Similar to spiral life-cycle model Improved communication among the people working on the same project with the Unified Modeling Language (UML) –A set of diagrams to specify, visualize, construct and document software –de facto industry standard for modeling software –

21 System Intro to UML: Use Case Diagrams Use-case view Functionality of the system as perceived by external actors while they interact with the system Actor - user or other system Use case – a generic description of a system usage (a function requested) Example: insurance business

22 Goal 2: Quality Software Can Be Modified Must be readable and understandable to humans –Problem must be understood before it can be solved Must be well designed –Easy to determine where to apply changes Must be able to withstand changes easily –Partition programs into manageable pieces that work together to solve the problem, yet are relatively independent

23 Goal 3: Quality Software Is Reusable Purpose: –Get as much value from the product as possible Quality software takes significant time and effort to be created –Reuse from previous projects to save time and effort: Programs Classes Methods Must be well-documented and easy to read –Time and effort spent on learning and adjusting reusable software must not exceed the time and effort to develop new similar software Shall have simple interface –To be easily plugged into a new system Shall be modifiable –To alleviate changes necessary to adapt to the new system Attempt to make software more generally useable –whenever it requires minimal extra effort –also, often a trade-off with performance

24 Goal 4: Quality Software Is Completed On Time and Within Budget A program that meets its functional requirements is not useful if it is not ready when needed Possible consequences of being late: –User dissatisfaction (may take business elsewhere) –Monetary penalties for missed deadlines –Beaten by competitors and lose market share –Forced out of business

25 1.2 Types of Programming Monolithic Programming –non-breakable code; redoing same tasks; excessive jumps (goto s ) (bad) Early years – till 1960s Structured Programming –A disciplined approach to writing programs that are cleaner, easier to test, debug and modify –A program execution is directed by a direct sequence of elementary operations (statements) – sequential execution (default) a flow of control structures that can create branches or loop same code while some condition tests true – transfer of control procedures or functions – a building block of program – a part of code packed together that most likely is created to do just one specific assignment (good!). Can be nested inside one another. Born to avoid problem with late deliveries, exceeding costs, etc. Object-Oriented Programming (OOP) –A programming methodology that views a program s a collection of similarly constructed objects that interact with one another to produce desired action. –Is build on top of Structured Programming

26 An algorithm is a procedure for solving a problem in terms of: the actions to be executed the order in which these actions are to be executed. Must be expressed so completely and precisely, that can be followed up without the necessity to fill in the details or make decisions (no ambiquity) Usually is expressed with: Pseudo-code (Structured English) or Flowchart Structural Design Pseudo-code example ( Rise-and-Shine): 1.Get out of bed. 2.Get dressed. 3.Eat breakfast. 4.IF temperature outside is below 50 degrees THEN wear a coat, ELSE IF temperature outside is above 70 degrees THEN wear a short sleeve shirt, ELSE wear a suit END-IF. 5.IF it is raining THEN take the umbrella END-IF. 6.Drive to work. Flowchart (Sum of 2 numbers): Start Enter two whole numbers on a line: sum = n1 + n2 n1, n2 The sum is + sum end

27 Object Orientation Started with Simula 67 –by Kristen Nygaard and Ole-Johan Dahl, 1967 Objects are: –Prime modularization mechanism in OOP –Contain information: we say the objects have attributes behavior: we say the objects have responsibilities (actions) –Remember their internal state Benefits of Object Orientation: 1.Can represent real-world entities, i.e. bank accounts 2.Objects are self-contained and are easy to: implement modify test for correctness 3.Object-oriented classes, when designed properly, are very easy to reuse

28 1.3 Classes, Objects, and Applications An object is an instantiation of a class A class defines the structure of its objects. A class definition includes: –variables (data) –methods (actions determining the behavior of an object).

29 Java Access Control Modifiers Within the Class Within Subclass in the Same Package Within non- subclass in the Same Package Within Subclass in Other Package Every where publicXXXXX protectedXXX packageXXX privateX

30 Inheritance Allows programmers to create a new class that is a specialization of an existing class We say that the new class is a subclass of the existing class, while the existing class is the superclass of the new class Also, common terms are parent / child

31 2 nd UML Diagram: Class Diagram Class diagram basics: Each class is a rectangular divided into 3 vertical parts Top is the name of the class Middle is data members (one per line) listed as: : Bottom is class methods (one per line) listed as: ([ : [, : param2_type>]…]): Inheritance is represented by symbol (from a child class to a parent) Private members use - in front of name, public – +, protected – #, package – ~

32 Todays Homework Make sure you have working Java environment –Recommend to download UML-generating tool (ArgoUML, etc.) Exercise 15b and 16 (due next week) –Follow Syllabus guidelines for complete documentation and submission