Exam 2 Review Software Engineering CS 561

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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.