SOEN 343 Software Design

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

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

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?

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

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!

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

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 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 • Creator • Information Expert • Controller • Low Coupling • High Cohesion • Polymorphism • Pure Fabrication -- NO • Indirection -- NO • Protected Variations -- NO

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?

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 be updated? • Change is inevitable, evolutionary design recognizes this. • As software is changed, generally it becomes more complexunlesseffort is made to keep it simple.

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? • 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 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 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 its behavior. • (More on this later)

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 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), 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 following “objects” have: … • To know. • To do. • To decide.

Design Principles Design for change

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: • Give examples of code that creates coupling.

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? • 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”. • (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 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 build upon each other to provide increased functionality.

Design Model

Logical Architecture – Simple Layers

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

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 of the following choices: • A façade controller, which represents • 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 visibility to B. It doesn’t happen by “magic.” • Kinds of visibility: • Attribute • Parameter • Local • Global Larman ch 19

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 Encapsulation

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?

SOEN 343 Software Design