Your SlideShare is downloading. ×
  • Like
  • Save
Object Oriented Analysis and Design with UML2 part2
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Object Oriented Analysis and Design with UML2 part2

  • 1,584 views
Published

Object Oriented Analysis and Design with UML2

Object Oriented Analysis and Design with UML2

Published in Technology , Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,584
On SlideShare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
0
Likes
10

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Use case realization is the set of class diagrams and interaction diagrams that implement a use case
  • Data model that can be changed to domain model
  • There is no such thing as a "correct" list. It is a somewhat arbitrary collection of abstractions and domain vocabulary that the modelers consider noteworthy
  • Fact: Each responsibility is an axis of change. Reminder: We must agree that if a change occurred on a class, then all the dependencies must be: Rebuild Retest Redeploy Because we have many responsibilities then we have many reasons to change which means a huge rebuild, retest and redeploy for all the clients
  • Geometric Rectangle has less reasons to change which means less probability to change the class. But if you are sure it will change, then use Design Patterns (Strategy design pattern)
  • LSP violation means you need to re-design your abstractions hierarchy.
  • Through the discussion of SOLID principles, we show some useful principles to apply through the design by showing classes with problems and solving them; but we didn’t show how did we get these classes and how did we assign their responsibilities. In the following section we will talk about how to find the responsibilities and how to assign the proper responsibility to the proper class.

Transcript

  • 1. Object-Oriented Analysis and Design with UML2 – Part 2 Presented By Haitham Raik
  • 2. Agenda
    • Part 1:
      • OO Analysis and Design Overview
      • UML Overview
      • Requirements Overview
      • Use Cases Overview
      • Basic OO Concepts
      • Architectural Analysis
  • 3. Agenda (cont.)
    • Part 2:
      • Object-Oriented Analysis
      • Object-Oriented Design
        • Design Principles Pyramid
        • Basic OO Design Principles (SOLID)
        • G eneral R esponsibility A ssignment S oftware P rinciples (GRASP)
        • Design Patterns
  • 4. Part2 Agenda
    • Object-Oriented Analysis
    • Object-Oriented Design
      • Design Principles Pyramid
      • Basic OO Design Principles (SOLID)
      • G eneral R esponsibility A ssignment S oftware P rinciples (GRASP)
      • Design Patterns
  • 5. Object-Oriented Analysis Now We are Here
  • 6. Object-Oriented Analysis
    • Also called Use Case Analysis
    • Performed by the designer.
    • Input:
      • Use Case Model
      • Logical Architecture
    • Output:
      • Domain Model/Analysis Model/Conceptual Model
  • 7. Object-Oriented Analysis
  • 8. Object-Oriented Analysis
    • What is the Concept?
      • It is an Idea, thing, or object that is essential to the business domain, without reference to implementation or technology.
      • For example, a banking system has the following concepts:
        • Customer
        • Account
        • Transaction
        • Loan
      • Concepts also called Analysis classes/Domain classes.
  • 9. Object-Oriented Analysis
    • What is a Domain Model?
      • It is a visual dictionary of noteworthy abstractions, domain vocabulary, and information content of the domain.
      • It is easier to understand the domain concepts in a visualize language.
  • 10.
    • Step 1: How to find Concepts?
      • Reuse or modify existing models.
      • Use a category list.
      • Identify noun phrases.
  • 11.
    • Find Concepts - Reuse or modify existing models:
      • First, Best, and easiest approach.
      • There are many published domain models and data models for many common domains, such as:
        • Finance
        • Health
        • Inventory.
      • References:
        • Analysis Patterns by Martin Fowler.
        • Data Model Patterns by David Hay.
  • 12.
    • Find Concepts - Use a Category List:
      • Examples from Flight Reservation and POS System.
    Category Examples Transaction Sale, Payment, Reservation Transaction Line Item Sales Line Item Product or Service Item, Flight, Seat, Meal Roles, People or organizations Cashier, Customer Place Airport Physical objects Airplane Description of thing Flight Description Catalogs Product Catalog Containers of things Store
  • 13.
    • Find Concepts - Identify Noun Phrases:
      • Identify the nouns and noun phrases in the use cases.
      • Filter the nouns using the following:
        • Is it outside the system boundaries?
        • Does it have identifiable structure?
  • 14.
    • Find Concepts - Identify Noun Phrases:
    • Example - Process Sale:
    • A customer arrives at a checkout with goods to purchase.
    • The cashier starts a new sale .
    • The cashier enters item identifier .
    • The system records line item and presents a running total and product description .
    • Cashier repeats steps 3-4 until indicates done.
    • The customer enters payment information, which the system validates and records.
    • The system updates inventory .
    • The customer receives a receipt from the system and then leaves with the items .
  • 15.
    • Find Concepts - Identify Noun Phrases:
      • List of Nouns:
        • Customer (Outside of the system)
        • Checkout
        • Goods (I will rename it to Product)
        • Cashier (Outside of the system)
        • Sale
        • Item Identifier (does not have structure)
        • System (this is what we want to understand)
        • Line Item
        • Running Total (does not have structure)
        • Product Description
        • Payment
        • Inventory
        • Receipt
  • 16.
    • Find Concepts - Identify Noun Phrases:
      • List of Nouns after filtering them:
        • Checkout
        • Product
        • Sale
        • Line Item
        • Product Description
        • Payment
        • Inventory
        • Receipt
  • 17.
    • Step 2: Create Analysis Diagram/Conceptual Diagram
  • 18.
    • Step 3: Add Associations:
      • Show associations when the knowledge of the relationship needs to be preserved for some duration (“need-to-remember” associations).
        • For example:
          • There is a need to remember the relationship between Sale and its Line Items (to calculate the total price).
          • Cashier may look up product description, but there is no need to remember the relationship between Cashier and Product Descriptions.
      • Identify the type of relationship: dependency, association, or generalization.
      • For association relationships, identify the multiplicity.
  • 19.
    • Review: Modeling Associations using UML
  • 20.
    • Association Naming:
      • Name an association based on a:
      • ClassName-VerbPhrase-ClassName format, where the verb phrase creates a sequence that is readable and meaningful.
      • For example:
        • Sale Paid-by Payment
        • Sale Contains Line Item
        • Line Item Records-sale-of Product
        • Product Description describes a Product
  • 21.
    • Associations Example:
  • 22.
    • Step 4: Add Attributes:
      • Include attributes that the use cases imply a need to remember information.
      • Examples:
        • Item Identifier
        • Sale total
      • Applying UML:
  • 23.
    • Add Attributes Guidelines:
      • Attribute types should be primitives, such as numbers and Booleans (does not have structure).
      • Relate conceptual classes with an association, not with an attribute.
  • 24.
      • Add Attributes Guidelines (Cont.):
        • No Attributes Representing Foreign Keys
  • 25.
    • Exercise:
      • Create Domain Model for one of the use cases we have presented in Part 1 of the presentation.
  • 26.
    • Domain Model and Domain Layer
      • Software class names in the domain layer are inspired from names in the domain model
      • Software classes attributes in the Domain Layer are inspired from the Domain Model.
      • The Model in M VC is an old OO term from the late 1970s; it is a synonym for the Domain Layer.
  • 27.
    • Domain Model is not a Data Model:
      • Data model shows persistent data to be stored somewhere.
      • So do not exclude a class because
        • The requirements don’t indicate obvious need to store the class.
        • The concept has no attributes
  • 28.
    • Recommended References:
      • Applying UML and Patterns
      • Analysis Patterns by Martin Fowler.
      • Data Model Patterns by David Hay
  • 29.  
  • 30. Part2 Agenda
    • Object-Oriented Analysis
    • Object-Oriented Design
  • 31. Object-Oriented Design Now We are Here
  • 32. Object-Oriented Design
    • Also called Use Case Design
    • Performed by the designer.
    • Input:
      • Use Case Model
      • Logical Architecture
      • Domain Model
    • Output:
      • Design Model
  • 33.
    • This objective:
      • Learn what a good design mean.
      • Learn the basic principles of a SOLID design.
      • Learn the GRASP principles as a guidelines to create a SOLID design.
      • Learn the design patterns as common design solutions for common design problems
  • 34.  
  • 35.
    • What a Good Design Mean?
      • It will lead to a system that:
        • Meets the customer requirements.
        • Easy to understand.
        • Easy to maintain.
        • Easy to extend.
        • Re-usable.
  • 36.
    • Basic Principles of SOLID design:
      • S ingle Responsibility Principle
      • O pen-Closed Principle
      • L iskov Substitution Principle
      • I nterface Segregation Principle
      • D ependency Inversion Principle
  • 37.  
  • 38.
    • Single Responsibility Principle:
      • A class should have one and only one type of responsibilities.
      • If a class assumes more than one responsibility, then
        • there will be more than one reason for it to change.
        • It will be highly coupled
      • High probability of change for a high coupled class will lead to frequent huge rebuild, retest and redeploy (Not easy to maintain).
  • 39.
      • The Rectangle class has two responsibilities
      • Two different applications use the Rectangle class (high coupling)
      • Drawbacks:
        • We must include the GUI in the computational geometry application (Not easy to reuse)
        • If one of the responsibilities changed, that change may affect the both clients which forces us to:
          • Rebuild, retest, and redeploy the both applications.
  • 40.
    • The solution:
      • If Rectangle class changed, then only the Graphical Application will be affected (Easy to maintain)
      • But what about Geometric Rectangle class? If it changed it will affect the both applications, right?
  • 41.  
  • 42.
    • Open/Closed Principle:
      • Can be used when a single change cascade changes to dependent modules
      • Module should be:
        • Open for extension
          • The behavior can be extended
        • Closed for modification.
          • No one is allowed to make a source code changes to it.
      • How can these two opposing attributes be resolved?
        • By Applying Polymorphism
  • 43.
    • For example:
      • If there is a need to change the Server class, we are forced either:
        • To open the Server class and modify it which may affect the client (rebuild, retest, redeploy).
        • Or to create a new class “Server2” and change the Client class.
      • The solution:
        • If a change is required, we can create new implementation of the interface
  • 44.
    • Open/Closed Principle:
      • Closed for Modification:
        • Since the client depends on a fixed interface (or abstract base class).
      • Open for extension:
        • The behavior can be extended by creating new implementation (sub class) of the interface (base class).
  • 45.  
  • 46.
    • Liskov Substitution Principle:
      • Method that use reference to “Base Class” must be able to use objects of “Derived Class” without knowing it .
      • LSP is a complementary for OCP.
      • In other words,
        • OCP says the client must interact with interface/base class
        • LSP says the client must not know any thing about the implementations/derived classes of that interface/base class.
      • The Consequences of Violating LSP:
        • Violating the LSP means the client must know about the implementation.
        • If the implementation changed, then the client will be affected.
  • 47.
    • The following code violates LSP:
    • public class Client {
      • public void violateLSPMethod(ServerInterface server) {
        • // This method must know about the impl class, which violates LSP
        • if (server instanceof ServerImpl1) {
        • //cast to ServerImpl1, then do something
        • }
        • if (server instanceof ServerImpl2) {
        • //cast to ServerImpl2, then do something different
        • }
        • // if a new implementation created, then we need to open this method and
        • // modify it, which violates OCP
      • }
    • }
    • // Conclusion: Violating LSP will lead to violate OCP
  • 48.
    • LSP violation indicates that the abstractions hierarchy is not correct.
    • How to solve LSP violation:
      • Re-design your abstractions hierarchy
      • For example:
        • KingFisher is a Bird and it can sing and fly.
  • 49.
    • But what if we added Ostrich to hierarchy
      • Ostrich is a bird but it can’t fly
        • The client code must be changed to include the following:
        • if (bird instanceof Ostrich) { // Violate LSP
        • // don’t call fly method
        • }
  • 50.
    • Solution:
      • Re-design your birds hierarchy
  • 51.  
  • 52.
    • Dependency Inversion Principle
      • High level modules should not depend upon low level modules. Both should depend upon interface/base class.
      • DIP is a generalization for OCP and LSP
      • For example, we have a copy program that reads a char from keyboard and write the char to a printer.
  • 53.
      • In the previous example, we will have code similar to the following:
    • void copy() {
      • KeyboardReader r = new KeyboardReader();
      • PrinterWriter w = new PrintWriter();
      • int c;
      • While ((c = r.read()) != EOF) w.write(c);
    • }
  • 54.
      • What if we want to re-use the copy program, to read from keyboard and write to disk; The code will be changed as following:
    • enum OutputDevice {printer, disk};
    • void copy(OutputDevice dev) {
      • KeyboardReader r = new KeyboardReader();
      • PrinterWriter printer = new PrintWriter();
      • DiskWriter disk = new DiskWriter();
      • int c;
      • While ((c = r.read()) != EOF) {
      • if (dev == printer) printer.write(c);
      • else disk.write(c);
      • }
    • }
  • 55.
      • Adding new device will increase the copy program dependency on low level implementations
      • The drawback of the dependency on low-level implementations is:
        • Any change on any low-level implementation will lead to: Rebuild, Retest and re-deploy.
      • The copy program in the previous example is not reusable (Not easy to re-use).
  • 56.
      • The solution:
        • depend on interface/abstract base class (DIP)
          • Low level implementation must depend on abstract class/interface
          • High level implementations (Policies) must also depend on abstract class/interface
  • 57.
      • After applying DIP, the code will be:
    • interface Reader {
    • int read();
    • }
    • interface Writer {
    • void write(int c);
    • }
    • // new impl. For copy program
    • void copy(Reader r, Writer w) {
      • int c;
      • While ((c = r.read()) != EOF) w.write(c);
    • }
  • 58.
    • Mitigating Forces
      • The DIP makes the assumption that anything concrete is volatile (not stable).
      • There are exceptions, for example:
        • the String class is a concrete class but stable.
        • Depending upon stable classes is not bad.
    • Object creation:
      • To create an instance, you must depend upon a concrete class.
      • There is a solution to this problem:
        • Dependency Injection (framework managed dependency injection),
        • Factory Design Pattern (Manual Dependency injection),
        • Service Locator
  • 59.  
  • 60.
    • Interface Segregation Principle
      • Client should not be forced to depend on methods they don’t need.
      • Sometimes, there are a need to violate SRP.
        • One class has many responsibilities.
      • ISP suggests that clients should not know about that as a single class.
      • Make fine grained interfaces that are client specific:
        • Each client should know about one interface that have a single responsibility.
  • 61.
    • For example:
      • Service class violates SRP (has many responsibilities)
      • The change on any of Client A method, will affect Client B and Client C.
  • 62.
    • Solution:
      • Create client specific interfaces.
  • 63.
    • Recommended References:
      • Applying UML and Patterns
      • Agile Software Development, Principles, Patterns, and Practices, Robert C. Martin
  • 64.  
  • 65.
    • Responsibility Assignment