SOEN 343 Software Design Section H Fall 2006

  • Slides: 44
Download presentation
SOEN 343 Software Design Section H Fall 2006 Dr Greg Butler http: //www. cs.

SOEN 343 Software Design Section H Fall 2006 Dr Greg Butler http: //www. cs. concordia. ca/~gregb/home/soen 343 h-f 06. html

Midterm Review • Midterm Wednesday 18 October 2006 at 13: 20 for 60 minutes

Midterm Review • Midterm Wednesday 18 October 2006 at 13: 20 for 60 minutes • Midterm covers Larman chapters 1 to 21 – But emphasis on chapters 17, 13, 19, 18 • Nothing from Fowler’s EAA – but layers, MVC included • You need to – write Java code and – draw UML diagrams

Midterm Review Week 1

Midterm Review Week 1

Basic Questions (Let’s Discuss) What is software design? How is it different from software

Basic Questions (Let’s Discuss) What is software design? How is it different from software programming? Software development? How do we design software? What is the role of objects, layers, architecture, . . ? What is the role of tests, responsibilities, patterns, models, …? How does design fit into the software lifecycle? What is good design? How does software design differ from … design?

Course Objectives • “Think in Objects” • Practice • Analyze requirements with • Apply

Course Objectives • “Think in Objects” • Practice • Analyze requirements with • Apply agile modeling use cases • Design object solutions • Create domain models – Assign responsibilities to objects • Apply an iterative & agile Unified Process (UP) • Relate analysis and design artifacts • Read & write highfrequency UML – Design collaborations – Design with patterns – Design with architectural layers – Understand OOP (e. g. , Java) mapping issues

What the course is: A (first) look at OO design! Design process: domain model,

What the course is: A (first) look at OO design! Design process: domain model, use cases, design Emphasis: models, GRASP principles, design patterns, responsibility, collaboration Mentions: RDD, TDD, MDD, extensibility Closely follows textbook!

What is OO Analysis and Design • Object-Oriented Analysis • Object-Oriented Design – Important

What is OO Analysis and Design • Object-Oriented Analysis • Object-Oriented Design – Important domain concepts or objects? – Design of software objects – Vocabulary? – Responsibilities – Collaborations – Visualized in the UP Domain Model – Design patterns – Visualized in the UP Design Model

Important Concepts Model • Abstraction hiding (unimportant) details • Eg, cover of Larman’s book

Important Concepts Model • Abstraction hiding (unimportant) details • Eg, cover of Larman’s book GRASP Principle • for assigning responsibility Design pattern • Solution to design problem in context • Eg, Command pattern

Responsibility-Driven Design (RDD) • Detailed object design is usually done from the point of

Responsibility-Driven Design (RDD) • Detailed object design is usually done from the point of view of the metaphor of: – Objects have responsibilities – Objects collaborate • Responsibilities are an abstraction. – The responsibility for persistence. • Large-grained responsibility. – The responsibility for the sales tax calculation. • More fine-grained responsibility.

The 9 GRASP Principles 1. 2. 3. 4. 5. 6. 7. 8. 9. Creator

The 9 GRASP Principles 1. 2. 3. 4. 5. 6. 7. 8. 9. Creator Information Expert Controller Low Coupling High Cohesion Polymorphism Pure Fabrication -- NO Indirection -- NO Protected Variations -- NO

Midterm Review Week 2

Midterm Review Week 2

OO Basics: Static vs. Dynamic Typing • Why not declare all fields or variables

OO Basics: Static vs. Dynamic Typing • Why not declare all fields or variables of reference types as – Object – void * (C++) • What would we gain? • What would we loose?

Midterm Review Week 3

Midterm Review Week 3

What is Design? Developing a blueprint (plan) for a mechanism that performs the required

What is Design? Developing a blueprint (plan) for a mechanism that performs the required task, … taking into account all the constraints, & … making trade-offs between constraints when they are in conflict.

Evolutionary Design • What is the probability that a S/W design will need to

Evolutionary Design • What is the probability that a S/W design will need to be updated? • Change is inevitable, evolutionary design recognizes this. • As software is changed, generally it becomes more complex unless effort is made to keep it simple.

Prerequisites to Successful Evolutionary Design? • Testing – … lots of automated testing. •

Prerequisites to Successful Evolutionary Design? • Testing – … lots of automated testing. • Refactoring – … keeping the design simple. • Continuous integration • Actually, testing is a prerequisite to refactoring.

Can you pick out a good design? • What is a good design? –

Can you pick out a good design? • What is a good design? – Satisfies user needs. – Is a simple as possible. Kent Beck: • • Runs all tests Reveals intention. No duplication. Fewest number of classes or methods • … can you smell bad design choices?

Test Driven Design • Write tests first. – Why does it make sense to

Test Driven Design • Write tests first. – Why does it make sense to write tests first? • TDD in its pure form – Do not add any (product) code unless a test failing.

Responsibility-Driven Design (RDD) • Detailed object design is usually done from the point of

Responsibility-Driven Design (RDD) • Detailed object design is usually done from the point of view of the metaphor of: – Objects have responsibilities – Objects collaborate • Responsibilities are an abstraction. – The responsibility for persistence. • Large-grained responsibility. – The responsibility for the sales tax calculation. • More fine-grained responsibility.

Object Responsibilities • A responsibility is an obligation of an object in terms of

Object Responsibilities • A responsibility is an obligation of an object in terms of its behavior. • (More on this later)

Information Expert • “… expresses the common ‘intuition’ that objects do things related to

Information Expert • “… expresses the common ‘intuition’ that objects do things related to the information they have. ” • Assign the responsibility for “knowing” [something] to the object (class) that has the information necessary to fulfill the responsibility.

Creator • Assign to class B the responsibility to create an instance of class

Creator • Assign to class B the responsibility to create an instance of class A if – B aggregates A objects. – B contains A objects. – B records instances of A objects. – B closely uses A objects. – B has the initializing data that will be passed to A when it is created.

GRASP: Polymorphism Principle Larman: • When related alternatives or behaviors vary be type (class),

GRASP: Polymorphism Principle Larman: • When related alternatives or behaviors vary be type (class), assign responsibility for the behavior—using polymorphic operations—to the types for which the behavior varies. • (This principle was illustrated last week with the Animal hierarchy. )

Responsibilities – A Boat Metaphor • What kind of responsibilities do each of the

Responsibilities – A Boat Metaphor • What kind of responsibilities do each of the following “objects” have: … – To know. – To do. – To decide.

Midterm Review Week 4

Midterm Review Week 4

Design Principles Design for change

Design Principles Design for change

Cohesion • Measure of the degree of “relatedness” that elements within a module share.

Cohesion • Measure of the degree of “relatedness” that elements within a module share. • Degree to which the tasks performed by a single module are functionally related. • Brain storm: – Why put procedures/methods together within a module/class?

Coupling • Measures the degree of dependency that exists between modules. • Brain storm:

Coupling • Measures the degree of dependency that exists between modules. • Brain storm: – Give examples of code that creates coupling.

Design – Repeat Successes • Has a (successful) similar product been built? • Yes,

Design – Repeat Successes • Has a (successful) similar product been built? • Yes, then reuse domain specific: – Architectural • Style (e. g. client/server, database, process control) • Patterns. – Design Patterns (& idioms). • Use Domain model as source of inspiration.

Design – New Application Area? • Has a (successful) similar product been built? •

Design – New Application Area? • Has a (successful) similar product been built? • No, then choose among general: – Architectural • Style (e. g. client/server, database, process control) • Patterns. – Design Patterns (& idioms). • Use Domain model as source of inspiration.

Layering – General Scheme Layers • Presentation / Application. – UI. – Generally “thin”.

Layering – General Scheme Layers • Presentation / Application. – UI. – Generally “thin”. – (Term “application” can be misleading. It does not mean …) • Domain / Business Logic. – Core system functionality. • Technical Services.

Domain Logic (Layer) • “… also referred to as business logic. … It involves

Domain Logic (Layer) • “… also referred to as business logic. … It involves calculations based on inputs and stored data, validation of any data that comes in from the presentation, and figuring out exactly what data source logic to dispatch …” [Fowler, p. 20]

Layered Style Characteristics • Each layer offers services to layers above. • Hence, layers

Layered Style Characteristics • Each layer offers services to layers above. • Hence, layers build upon each other to provide increased functionality.

Midterm Review Week 5

Midterm Review Week 5

Design Model

Design Model

Logical Architecture – Simple Layers

Logical Architecture – Simple Layers

Model-View-Control Architecture (MVC) Model • maintains the state and data of the application -

Model-View-Control Architecture (MVC) Model • maintains the state and data of the application - the XML document View • A rendering of the XML document Controller • The user interface presented to the user to manipulate the application

Traceability

Traceability

PATTERN: Controller (Larman 17. 13) Problem: What object in the domain (or application coordination

PATTERN: Controller (Larman 17. 13) Problem: What object in the domain (or application coordination layer) receives requests for work from the UI layer? System operations (see SSD): major input events to the system The controller is the first object beyond the UI layer that is responsible for receiving or handling a system operations message. Note that UI objects delegate system operation request to a controller.

PATTERN: Controller (Larman 17. 13) Solution: Assign the responsibility to a class representing one

PATTERN: Controller (Larman 17. 13) Solution: Assign the responsibility to a class representing one of the following choices: • A façade controller, which represents 1. 2. 3. 4. • the overall system A root object A device that the software is running within, or A major subsystem A use case or session controller which represents a use case scenario in which the system operation occurs

Designing for Visibility • Fact: To send a message to B, A must have

Designing for Visibility • Fact: To send a message to B, A must have visibility to B. It doesn’t happen by “magic. ” • Kinds of visibility: – – Attribute Parameter Local Global Larman ch 19

Midterm Review Week 6

Midterm Review Week 6

Encapsulation • A programming/design language mechanism. • A packaging / scoping mechanism for names

Encapsulation • A programming/design language mechanism. • A packaging / scoping mechanism for names – Names can refer to data, types, … – Especially, a means of packaging data. Access points at interface

Information Hiding • Design principle by which a module is assigned a “secret”. •

Information Hiding • Design principle by which a module is assigned a “secret”. • A module’s secret is usually – A design decision. • What type of design decisions might we want to hide from the clients of a module?