CS 5150Software

EngineeringLecture 15

Program Design 2

2CS 5150

Administrivia

• TAs reading milestone 2 reports

• Everyone do teammate feedback?

• Quiz 2

• No final exam

3CS 5150

General Presentation Feedback

• Client single point of contact

4CS 5150

SE in the News

•Google releases Dart SDK

•Largest Kickstarter project funded -- $4M

•Microsoft app store craziness

•Zero-day exploit lifecycle analysis

5CS 5150

Conditions on MSFT’s App Store5.2 Your app must not contain content that advocates discrimination, hatred, or violence based on membership in a particular racial, ethnic, national, linguistic, religious, or other social group, or based on a person’s gender, age, or sexual orientation5.3 Your app must not contain content or functionality that encourages, facilitates or glamorizes illegal activity5.4 Your app must not contain or display content that a reasonable person would consider to be obscene5.5 Your app must not contain content that is defamatory, libelous or slanderous, or threatening5.6 Your app must not contain content that encourages, facilitates or glamorizes excessive or irresponsible use of alcohol or tobacco products, drugs or weapons5.7 Your app must not contain content that encourages, facilitates or glamorizes extreme or gratuitous violence, human rights violations, or the creation or use of weapons against a person or animal in the real world5.8 Your app must not contain excessive or gratuitous profanity

6CS 5150

Attack Timeline

7CS 5150

8CS 5150

Quiz 2

• Requirements

• Scenarios/use cases

• Diagrams: dataflow, flow chart, entity relation, sequence

• Usability

• Interface/user testing

• Software architecture

• Design patterns

• Concurrency

9CS 5150

Program Design

• The task of program design is to represent the software system functions in a form that can be transformed into one or more executable programs

• Given a system architecture, the program design specifies:

• programs, components, packages, classes and class hierarchies

• interfaces, protocols (where not part of the system architecture)

• algorithms, data structures, security mechanisms, operational procedures

• If the program design is done properly, all design decisions should be made before implementation

10

CS 5150

UML Models

• UML models (diagrams and specifications) can be used for almost all aspects of program design

• Diagram gives a general overview of the model, showing the principal elements and how they relate to each other.

• Specification provides details about each element of the model. Specification for models used in program design should have sufficient detail that they can be used to write code from.

11

CS 5150

Class Diagrams

12

CS 5150

Class Diagram in Rational Rose

13

CS 5150

Notation: Relationships

14

CS 5150

Like Database Schema

15

CS 5150

Notation: Relationships (continued)

16

CS 5150

Notation: Interface

17

CS 5150

Notation: Package

18

CS 5150

Modeling Classes

• Given a real-life system, how do you decide what classes to use?

• What terms do the users and implementers use to describe the system? They are candidates for classes.

• Is each candidate class crisply defined?

• For each class, what is its set of responsibilities? Are the responsibilities evenly balanced among the classes?

• What attributes and operations does each class need to carry out its responsibilities?

19

CS 5150

Candidate Classes: Application Classes and Solution Classes

• Application classes represent application concepts.

• Noun identification is an effective technique to generate candidate application classes

• Solution classes represent system concepts, e.g., user interface objects, databases, etc.

20

CS 5150

From Candidate Classes to Completed Design

• Methods used to move to final design:

• Reuse: Wherever possible use existing components, or class libraries. They may need modification.

• Restructuring: Change the design to improve, understandability, maintainability, etc. Techniques include merging similar classes, splitting complex classes, etc.

• Optimization: Ensure that the system meets anticipated performance requirements, e.g., by changed algorithms or restructuring.

• Completion: Fill all gaps, specify interfaces, etc.

21

CS 5150

Coupling and Cohesion

• Coupling is a measure of the dependencies between two part of a system. If two classes are strongly coupled, it is hard to modify one without modifying the other.

• Cohesion is a measure of dependencies within part of a system. If a class contains many closely related functions its cohesion is high.

• Aim for high cohesion within classes and weak coupling between them.