Exam 2 Review

Software EngineeringCS 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.