1. Review slides will be posted on the course web site:
Review for Exam #2: Chapters 10-13, 15, 19, 20 and Software Models from Design Document
Exam #2 – Thursday, Nov. 6
Review slides will be posted on the course web site:
Office hours
Dr. Skubic: Tues., 2-3:30 p.m. in EBW 221
Jason Goffeney: Tues., 12:30-1:50 p.m.
Wed., 1-3 p.m. in EBW 347 (or 350)

2. Thinking ahead…
Presentations on the Final Project will begin the week before Thanksgiving.
I will post a sign-up sheet outside my office – EBW 221.
Reminder – All of the team members must participate in the final project presentation.
Any problems or questions on the group project?

3. Chapter 10 Architectural Design
System Structuring
Decompose the system into interacting sub-systems  block diagram
Repository model – share lots of data
Client-server model – clients request services from servers (distributes the processing)
Control Modeling
Centralized control – one sub-system manages the rest call-return model vs. the manager model
Event-based control – Driven by external events broadcast models vs. interrupt-driven models
Modular Decomposition
Sub-systems are decomposed into modules
Object models vs. Data-flow models
The style and structure of the architecture usually depends on both functional and non-functional requirements

4. Homework #3 Solutions
1. Giving reasons for your answer, suggest an appropriate architectural model for the following systems (Chapter 10):
An automated ticket issuing system used by passengers at a railway station.
ANSWER: An appropriate model is a centralized model with a shared repository of route and pricing information. Thus, changes are immediately available to all machines. There is not much advantage to a client-server architecture, because little local processing is necessary. The centralized system also allows global information and route use to be collected and processed.

5. Homework #3 Solutions
1. Giving reasons for your answer, suggest an appropriate architectural model for the following systems (Chapter 10):
A computer-controlled video conferencing system which allows video, audio and computer data to be visible to several participants at the same time.
ANSWER: An appropriate model here is the client-server model. Local processing will be required here to handle multimedia data.

6. Chapter 11 Distributed Systems Architectures
Distributed  system software runs on a loosely integrated group of cooperating processors linked by a network.
Multiprocessor architectures
Simplest distributed model – Used for many real-time systems
Client-server architectures
Layers: presentation, application, data management
Fat client vs. thin client vs. 3-tier architecture
Distributed object architectures
Objects may act as producers or users of services – No distinction between clients and servers
Object communication is handled by an object request broker (ORB)
CORBA
An international standard for an ORB (also called middleware)

7. Homework #3 Solutions
2. What is the fundamental difference between a fat-client and a thin-client approach to client-server systems development? Explain why the use of Java as an implementation language blurs the distinction between these approaches. (Chapter 11)
ANSWER:In a fat-client system, some of the application processing is carried out on the client whereas in a thin client system only the user interface is displayed on the client and all of the application processing is carried out on the server. Java blurs the distinction as it allows the development of applets which can be downloaded to the client at execution time. Depending on the functionality of the applet, this allows a degree of control over the processing that is carried out on the client.

8. Homework #3 Solutions
3. Explain why the use of distributed objects with an object request broker simplifies the implementation of scalable client-server systems. Illustrate your answer with an example. (Chapter 11)
ANSWER: The use of distributed objects and an ORB simplifies the implementation of scaleable systems as it is very easy to add additional servers in the form of distributed objects to the system. These can be introduced without perturbing other parts of the system. An example would be a web server which can be easily replicated as the number of users increases.

9. Chapter 12 Object-Oriented Design
Objects and object classes
Relationship between classes and objects
Generalization and inheritance
Advantages and disadvantages
An object-oriented design process
Identify context and use cases
Design the architecture
Identify principal objects
Develop design models, e.g., sequence diagram and statecharts
Specify object interfaces
Design evolution
Information hiding inside objects means changes can be made without unpredictable side-effects

10. Homework #3 Solutions
4. Explain why adopting an approach to design that is based on loosely coupled objects that hide information about their representation should lead to a design which may be readily modified. (Chapter 12)
ANSWER: There are 2 major problems encountered when modifying systems:
Understanding which entities in a program are logically part of some greater entity.
Ensuring that changes do not have unanticipated side-effects (i.e., a change to one entity has an undesirable effect on some other entity).

11. Homework #3 Solutions, #4 cont.
ANSWER: Object-oriented development helps to reduce these problems as it supports the grouping of entities (in classes) so program understanding is simplified. It also provides protection for entities declared within objects so that access from outside the object is controlled (the entity may not be accessible, its name may be accessible but not its representation, or it may be fully accessible). This reduces the probability that changes to one part of the system will have undesirable effects on some other part.

12. Chapter 13 Real-Time Software Design
Correct functioning depends on both the results produced and the time at which these results are produced
‘Soft’ real-time vs. ‘Hard’ real-time
Systems design
Identify the stimuli, responses & timing constraints  concurrent processes
State machine model  State transition diagram
Real-time executives
Real-time clock, interrupt handler, scheduler, dispatcher, resource manager
Monitoring and control systems
Examples – burglar alarm system, temperature controller
Data acquisition systems
Using a ring buffer
Example – reactor flux data collection

13. Chapter 15 User Interface Design
Towards a user-centered interface driven by user needs
User interface design principles
User familiarity, consistency, minimal surprise, recoverability, user guidance, user diversity
User interaction
How to provide information from the user to the system
How to present information from the computer system to the user
Styles – direct manipulation, menus, forms, command line, natural language
Information presentation
static vs. dynamic displays
graphical vs. text; analog vs. digital
User support
System help and error messages; user documentation
Interface evaluation
Usability studies; surveys to gather user opinion

14. Chapter 19 Verification and Validation
Verification – Are we building the product right?
Validation – Are we building the right product?
Software inspections vs. software testing
V & V planning
Start early and identify a balance
Software Inspections
Examine the requirements document, design diagrams, code, …
Automated Static Analysis
Parse the code for errors in control flow, use of variables, …
Cleanroom Software Development
Formal specification using a state transition model
Incremental development and structured programming
Static verification and statistical testing

15. Chapter 20 Software Testing
Defect testing
a successful test exposes a previously unknown defect
black-box testing vs. white-box testing (structural testing)
choosing test cases with equivalence partitioning
path testing and cyclomatic complexity (#paths = #edges - #nodes + 2)
Integration testing
tests complete systems or sub-systems
top-down testing vs. bottom-up testing
interface testing
stress testing
Object-oriented testing
test individual classes and clusters of cooperating classes
object integration, e.g., use case or scenario testing
Testing workbenches

16. REVIEW – Software Models
Requirements
Use Case diagram
Context model
The context diagram
Behavioral model
Data flow diagram (also called process model)
State diagram
Data model
Entity-relationship diagram
Data dictionary
Object models
Hierarchy showing inheritance
Aggregation

17. Use Case Diagram:
factor out common functionality with <<include>>

18. Use Case Diagram: using <<extend>>

19. Use Case Diagram:
using a generalization

20. Context Diagram The context of an ATM system
ATM does NOT include the Account DB, etc.

21. Another Context Diagram from HW#2
Is the Medical Records System part of the Patient Information System?
patient information
system
image database
hospital
admissions
drug dispensing
medical
records

22. Data Flow Diagram: Equipment procurement process
Also called a Process Model

23. State Transition Diagram Microwave oven model
Also called a Statechart

24. Entity-Relationship Diagram http://members. iinet. net
Manager
Department
manages
is managed by
one to one relationship
has
works in
Employee
one to many relationship

25. Entity-Relationship Diagram Semantic Data model of a Software design

26. Class Diagram: Illustrating generation
Name of object class
Class Diagram: Illustrating generation
Class attributes
Object’s operations

27. Class Diagram: Object aggregation