190 likes | 441 Views
IST 311 – Object-Oriented Design & Software. Steven Haynes IST 311 – Class 1 10 January 2005 shaynes@ist.psu.edu. Syllabus Review. Core Material. Design and systems development theory Design and systems development skills derived from experience UML Java. Approach & Philosophy.
E N D
IST 311 – Object-Oriented Design & Software Steven Haynes IST 311 – Class 1 10 January 2005 shaynes@ist.psu.edu
Core Material • Design and systems development theory • Design and systems development skills derived from experience • UML • Java
Approach & Philosophy • Design depends on knowing your materials • Programming languages • Data structures • People • Application domain and context • Many application design problems are ‘wicked’, they require analysis (modeling) and experimentation (prototyping) to manage • Problem-based Learning
Participation • Good • Asking questions • Providing insights on course materials • Supplying material • Not-so-good… • Surfing, e-mail, e-chat in class • Sleeping • Excessive talking (to the point of disruption)
Texts • Software Systems Design and Development • Bruegge & Dutoit • Java • Raposa • UML • Ambler (Bruegge & Dutoit) • See also Resources page on course web site
Course Software • Java • Eclipse (labs and personal PC) • UML • MS Visio Professional (labs) • Poseidon CE (Free UML tool, a free download for your personal PC use.)
Course Projects • Course Project - design & develop an application of significant complexity • Mid-term project consists of initial designs • Final project consists of complete design and working application • Domain: a better degree audit tool…
UML Diagrams • Use Case diagram • Identify major services provided by a system to external actors (users and other systems) • Establish the boundaries of the system • Identify common functionality • Identify high-level alternate use scenarios • Capture requirements • Development project planning tasks • Communicate with the customer/user.
Use Cases • Actors • Use Cases • Include (Uses) Use Cases • Extend Use Cases • Annotations • Pre-conditions • Post-conditions • Constraints • Don’t use actor or use case generalization
Guidelines for Use Cases • Actors – specific user roles • Human actors on left • Non-human actors (systems) on right • Use Cases – verb-noun phrase • e.g., Verify Credit Card • Include (uses) link – included use case MUST be completed for the including use case to complete • Extend link – extending use case represents a variant of the extended use case
Scenario-Based Design • Scenarios are used to explicate and evaluate requirements, evolving designs, and systems in production • Envisioning scenarios – used to imagine what and how interaction support will be delivered by the system being designed • Evaluation scenarios – used to walk through an existing design to ensure that the model supports desired interactions • Scenarios are concrete instances of a use case
Scenario • Scenario Title – short description of the scenario • Actor – the person or role performing the scenario • Setting – a description of the context in which the scenario takes place • Scenario Goal – the objective of the interaction with the application being designed • Scenario Narrative – a detailed account of how you envision that the scenario actor will interact with the application to achieve the scenario goal • Claims Analysis – statements of what is required to support the interaction scenario. Claims should include explicit consideration of trade-offs, the pros and cons of different approaches to feature design.
Homework Assignment • This is an individual assignment. • Read Bruegge & Dutoit Ch. 1 • Write two scenarios, 1 actual and 1 envisioned, for the degree audit domain, 1 page each including all of the components discussed on the previous slide • Due at the start of class Thursday, 1/12. • Hand in hard copies and e-mail soft copies to shaynes@ist.psu.edu