Presentation is loading. Please wait.

Presentation is loading. Please wait.

Computer ScienceSoftware Engineering Slide 1 Groups Paul Simmerlink Stephen Herbert Daniel Coming Ogechi Ugwulebo James King Jigna J. Bhatt Casey J. Powell.

Similar presentations


Presentation on theme: "Computer ScienceSoftware Engineering Slide 1 Groups Paul Simmerlink Stephen Herbert Daniel Coming Ogechi Ugwulebo James King Jigna J. Bhatt Casey J. Powell."— Presentation transcript:

1 Computer ScienceSoftware Engineering Slide 1 Groups Paul Simmerlink Stephen Herbert Daniel Coming Ogechi Ugwulebo James King Jigna J. Bhatt Casey J. Powell Brett Harrison Jonathan Ward Michael Vidal Don Miller James Frye David Brewer Olja Mihic Casey Mees Maggie Lu Reid Webber Taisuke Nagayama Jeff Payne Matasaka Sako Howard C. Wu Shana Rheault RichardD.VanHorn Rodel Mangoba Steve Luong Jason Dodd Beifang Yi Dorothy P. Cheung William Nelson Will Woolsey Andrew Rodgers James Cohen, Judy Rowley, Stan Sexton, Rajashekhar Yakkali, Kazuhito Mori

2 Computer ScienceSoftware Engineering Slide 2 Project Management tools l See the projects web page l Concurrent Versions System (CVS) l Coding standards Java coding standard document

3 Computer ScienceSoftware Engineering Slide 3 What have we learned so far? l Murphy's Technology Laws 1. Logic is a systematic method of coming to the wrong conclusion with confidence. 2. Whenever a system becomes completely defined, some damn fool discovers something which either abolishes the system or expands it beyond recognition. 3. Nothing ever gets built on schedule or within budget. 4. All's well that ends. 5. Any given program, when running, is obsolete. 6. To spot the expert, pick the one who predicts the job will take the longest and cost the most.

4 Computer ScienceSoftware Engineering Slide 4 What have we learned so far? l The first step in software development is understanding the system to be developed l This is requirements analysis l Requirements analysis starts with a description of the system l The description is refined into a requirements document

5 Computer ScienceSoftware Engineering Slide 5 Requirements document l Interaction between engineering, marketing and clients (domain experts) l Iterative l Increase understanding of system Informal scenarios help understanding and appreciation of system complexity Raise questions that need to be answered by domain experts Propose GUI/UI (more on GUI design later) l Requirements document (formatted formal document)

6 Computer ScienceSoftware Engineering Slide 6 Do you understand system? l Validate your understanding l Use Case Centered Design (UCCD) Scenarios Comprehensive, explore all interaction with system UML class diagrams Initial design List of primary classes (nouns, properties of primary classes) UML use-case diagrams Compact representation of use of system

7 Computer ScienceSoftware Engineering Slide 7 Next? l Troutman's Laws of Computer Programming 1. Any running program is obsolete. 2. Any planned program costs more and takes longer. 3. Any useful program will have to be changed. 4. Any useless program will have to be documented. 5. The size of a program expands to fill all available memory. 6. The complexity of a program grows until it exceeds the capability of its maintainers. 7. Any system that relies on computer reliability is unreliable. 8. Any system that relies on human reliability is unreliable. 9. Make it possible for programmers to write programs in English, and you will find that programmers cannot write in English. 10. Profanity is the one language all programmers know best.

8 Computer ScienceSoftware Engineering Slide 8 Next l Persistence? l Inter-process communication? l HCI l Architecture Grouping primary classes Interfaces l Design l Implementation l Validation

9 Computer ScienceSoftware Engineering Slide 9 Persistence l LMS l Galaxy sleuth l GPA

10 Computer ScienceSoftware Engineering Slide 10 Object Persistence l Object persistence seeks to retain object information on some persistent storage medium as a file or through a DBMS l Object serialization works for situations where all object information can reside in memory at once l Because most commercial DBMSs are relational in contrast to object-oriented, some translation between the object and relational representations must be made

11 Computer ScienceSoftware Engineering Slide 11 Evaluating Object Persistence l Security Hacker proof Allows reconstruction in face of malicious use l Information growth Solution still works with increased data volume l Concurrency Concurrency solution allows for increased users

12 Computer ScienceSoftware Engineering Slide 12 LMS: Object Persistence l LMS may contain hundreds of thousands of book entries as well as thousands of other library resources l such a volume of data does not permit object streaming l A DBMS is called for to provide Concurrent access by multiple users Security enforcement of different access levels for various user categories Allow for increased data capacity

13 Computer ScienceSoftware Engineering Slide 13 What do we want to persist? l System state ?

14 Computer ScienceSoftware Engineering Slide 14 LMS Case Study: Relational Representation of Data Relational TablesBook Resource List Patron Address Patron

15 Computer ScienceSoftware Engineering Slide 15 Process Architecture l Software systems may consistent of processes interacting over a network l Process architecture lays out the machines (nodes) that will host the processes making up the system l Process architecture determines the behavior of the distributed processes l Deployment diagrams are used to model distributed processes

16 Computer ScienceSoftware Engineering Slide 16 Sample Deployment Diagram Game Client Game Server Internet

17 Computer ScienceSoftware Engineering Slide 17 Modeling Interprocess Communication l Deployment diagrams show the distribution of process over multiple nodes but do not indicate how these processes communicate l State machines may be used to model communication between processes l The idea behind using state machines for modeling interprocess communication is that the system enters a new state when messages are exchanged between processes

18 Computer ScienceSoftware Engineering Slide 18 UML Notation for State Machines State Name Intermediate State Initial State Final State Trigger State transition with event trigger State Name State with substates

19 Computer ScienceSoftware Engineering Slide 19 Sample State Machine Showing Interprocess Communication Player Joining Game Get player name Select token { Client States} { Server State} Communicate remaining tokens player name available tokens selected token

20 Computer ScienceSoftware Engineering Slide 20 Modeling Multiple Threads of Control l Classes that consist of a separate thread of control are modeled as active classes l Active classes are rendered with thick rectangles as shown below Active class Regular class

21 Computer ScienceSoftware Engineering Slide 21 Galaxy Sleuth l galaxySleuthServer l gameBoard l playerListener

22 Computer ScienceSoftware Engineering Slide 22 Design Summary l Create solution for object persistence l Develop user interface designs l Determine process architecture

23 Computer ScienceSoftware Engineering Slide 23 Possible Obstacles to Effective Meetings l Poor agendas l Dysfunctional communication during the meeting (silence or domination) l Not adhering to the agenda l Discussion may not sufficiently focus on meeting objectives specified by the agenda l Team members are not listening to each other during discussion


Download ppt "Computer ScienceSoftware Engineering Slide 1 Groups Paul Simmerlink Stephen Herbert Daniel Coming Ogechi Ugwulebo James King Jigna J. Bhatt Casey J. Powell."

Similar presentations


Ads by Google