SOEN 343 Software Design Section H Fall 2006
- Slides: 44
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 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?
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, 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 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 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 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
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
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 complex unless effort 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.
Midterm Review Week 4
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.
Midterm Review Week 5
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 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 visibility to B. It doesn’t happen by “magic. ” • Kinds of visibility: – – Attribute Parameter Local Global Larman ch 19
Midterm Review Week 6
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”. • 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 385
- Soen 343
- Soen 343
- Soen 343
- Soen 6441 concordia
- Soen 6441
- Soen 6441
- Soen 385
- Soen 6441
- Soen 342
- Csc 343
- Texas health and safety code 343
- Experiment 343
- Experiment 343
- Cecs 343
- 343 descompus
- X3 = 64/343
- Cs 343
- 343 day
- Log 343
- 343*15
- 343 jesus
- Opwekking 343 tekst
- Find the percentage decrease from 490 to 343
- Mimi opkins
- Csc 343
- Factor 125x^3-64
- Real time software design in software engineering
- Design principles in software engineering
- Revolved sections
- Broken-out section view
- Full section vs half section
- Section 2 describing energy worksheet answers
- Chapter 10 section 1 meiosis
- A real friend 2006
- Sentencia c-355 de 2006
- Pengiktirafan ukm 2006
- Monarch awards 2006
- Syawal 2006
- T. trimpe 2006 http://sciencespot.net/
- Sexenio 2000 a 2006
- Que es la sentencia c 355 de 2006
- Pengiktirafan ukm 2006
- Rdc 214 de 2006
- Rose report 2006