1. Exam 2 Review Software Engineering CS 561

2. Outline Requirements Development UML Class Diagrams Design Patterns Users, Usability, and User Interfaces Software Processes Other Types of UML Diagrams Software Architecture and Design

3. Developing Requirements Content for requirements documents Size of the system The need to interface with other systems The target audience Contractual agreements for development Stage in requirements gathering Experience with the domain and the technology Costs incurred for incorrect requirements

4. Developing Requirements Guidelines for requirements Have benefits outweighing cost of development Important to solution of the problem Expressed clearly and consistently Made unambiguous and uniquely identifiable Verifiable and logically consistent Leading to a system of sufficient quality Work with available resources

5. Developing Requirements Additional guidelines Avoid over-constraint of the system Complete and well-organized Agreed upon by stakeholders – Problem – Background information – Environment and system models – Functional requirements – Quality, platform, and process requirements

6. Class Modeling UML – Unified Modeling Language – Standardized, managed by Object Management Group (OMG) – Used for class, interaction, state, activity, component, and deployment diagrams. – For class diagrams, it allows for modeling Capturing a set of information about a system

7. Class Modeling Class diagrams include – Classes – Associations – Attributes – Operations – Generalizations

8. Class Modeling Associations and Multiplicity – Associations used to show how two instances of classes reference each other – Muliplicity indicates how many instances of classes at the end of the association are linked to an instance of a class at the other end of the association – Associations may be labeled Labels should be a verb/verb phrase

9. Class Modeling Common multiplicities for associations include – One-to-many – Many-to-many – One-to-one Associations may be reflexive – Objects may be associated with themselves Associations may be directional – Only one class has references to the other

10. Class Modeling Association – Classes are referenced by one another Aggregation – Represents a part to whole relationship – Stronger than association – Can be represented as an association Composition – Represents a stronger part to whole relationship – The parts are destroyed when the whole is destroyed

11. Class Modeling Developing class diagrams – Exploratory domain model – System domain model – System model Identify classes, associations, and attributes Identify generalizations and interfaces Label them properly

12. Design Patterns Each design pattern includes – Context – Problem – Solution Presents a generalized solution to a common problem

13. Design Patterns Abstraction-Occurrence General Hierarchy (You should be able to use this one) Player-Role Singleton pattern Observer pattern Delegation pattern(You should be able to use this one)

14. Using Design Patterns Adapter pattern Façade pattern Immutable pattern (You should be able to use this one) Read-Only Interface pattern (You should be able to use this one) Factory pattern

15. Users User centered design – Understand users – Focus on SW that is based on understanding of users’ tasks – Keep users involved in decision making – UI should follow principles of usability – Get user feedback through out design and development process

16. Users Why focus on users? – Cheaper training and support – Gradual learning curve – Improved efficiency of use – Lowered development costs Make only needed features – Less expensive to change system later – More attractive system Users will want to utilize a well designed tool

17. Usability and Utility – Usability vs. utility Both define usefulness of software Usability is how easy users are able to learn and use the capabilities of a system Utility refers to a system having the ability to accomplish a task – Aspects of usability Learnability Efficiency of use Error handling Acceptability

18. UI Design UI Design Terminology – Dialog – Control or widget – Affordance – State – Mode – Modal dialog – Feedback – Encoding techniques

19. Usability Principles of usability Don’t rely only on guidelines, test with users UI design should be based on use cases defined by users’ tasks Action sequences to complete tasks in UI should be as simple as possible User should know what to do next and what will happen when he/she does it Error messages and feedback must be descriptive User should be able to undo, go back, or correct an action

20. Usability More principles of usability Adequate response time Descriptive labels and encoding techniques UI appearance must be neat and uncluttered Consider needs of different groups Provide help tools Be consistent throughout the UI

21. Other UML Diagrams Diagrams to model interactions – UML Sequence Diagrams Show a sequence of actions via methods over time Diagrams include objects, actors, lifelines, and activation boxes – UML Communication Diagrams Indicates a sequence of actions via methods Diagrams include objects and order of operations – UML State Diagrams Includes states and transitions between them – UML Activity Diagrams Similar to a flow chart

22. Software Architecture and Design Coupling – interdependencies between one module and another – Content, Common, Control, Stamp, Data, Routine Call, Type Use, Inclusion or Import, and External Cohesion - Stickiness, Adherence or Things that go together – Functional, Layer, Communicational, Sequential, Procedural, Temporal, and Utility

23. Software Development Processes Rational Unified Process Waterfall Process Spiral Process Agile Process

24. Reminders Previous material is fair game, but not the focus of the exam Study class notes and the text I will not be present. Instead, Abhyudaya will proctor the exam.