Your SlideShare is downloading. ×
0
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Object Oriented Analysis and Design with UML2 part1
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Object Oriented Analysis and Design with UML2 part1

4,273

Published on

Object Oriented Analysis and Design with UML2

Object Oriented Analysis and Design with UML2

Published in: Technology, Education
1 Comment
23 Likes
Statistics
Notes
No Downloads
Views
Total Views
4,273
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
0
Comments
1
Likes
23
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
  • Analysis means OO Analysis Design means OO Design
  • The three amigos
  • Functional and non-functional requirements, Functionality is our concern Usability : is the ease of use and learnability of a human-made object; how the user is going to use the system (there must be an UI interface, and there must be enough help for the user) Reliability : frequency of failure means how many times is allowed to fail in a period (let’s say a year). For example, the system must not fail more than 10 times in a year. predictability: by providing monitors (threshold) Performance :  is characterized by the amount of useful work accomplished by a system compared to the time and resources used Supportability : It refers to the ability of  technical support  personnel to install, configure, and monitor computer products, identify exceptions or faults,  debug  or isolate faults
  • Note the behaviors starts with a verb and indicate the system behavior
  • Partitioning (swim lane)
  • If you know 20 concepts of these 26 concepts, then you are fine. This chapter is really useful for job interviews :-D
  • Object characteristics can be properties and/or behavior
  • compartmentalizing
  • Hierarchy is based on the classification (finding the similarities and putting them in a more generic abstraction)
  • By finding similarities Some commonalities between abstraction in the same level can lead to a more generic abstraction that represents these commonalities (this called classificiation)
  • By finding similarities
  • Abstraction is the process of finding the related characteristics of an object, what is the object?
  • State is all properties (attributes and relationships)
  • Relationship between class and object
  • Attribute is a description of
  • Till the moment we didn’t talk about how to represent object in uml The properties values here are actual values that the object hold, not initial values
  • General relationships can be used at the early stages of analysis and design (when the relationships are not yet clear)
  • Object structure is the set of the object properties
  • Navigability and Multiplicity are applicable only on associations, aggregations and compositions There is nothing called dependency navigability or dependency multiplicity
  • Sometimes it is called Shared aggregation
  • Sometimes it is called Composite aggregation
  • UML Structured class is a different way that can be used to represent the composition and aggregation.
  • One instance of whole may have a reference to one instance or more of Part2 One instance of Whole may have zero or more instances of Part1
  • We must agree that if a change occurred on a class, then all the dependencies must be: Rebuild Retest Redeploy
  • For more information: http://publib.boulder.ibm.com/infocenter/rtnlhelp/v6r0m0/index.jsp?topic=%2Fcom.ibm.xtools.modeler.doc%2Ftopics%2Fcdepend.html
  • If we returned back to the principle hierarchy. Where the general abstractions at the top of the hierarchy and the specialized abstractions at the bottom of the hierarchy. Then the generalization relationship is the relationship between the general (at the top) and the specialized abstraction (at the bottom)
  • Use elided form in case you need to denote the existence of an interface Use canonical form in case you need to see the details of the interface
  • Interface1 is a provided interface by Class1 Class1 is the provider for the interface
  • Interface1 is required interface by Consumer In canonical form, the required interface is modeled using usage dependancy
  • Supporting the changing of the implementation without affecting the clients
  • The above describes what is a software architecture The software architect must cover the above views. In this step the focus will be on the Logical View. At the logical view the Software architect defines
  • How do you choose which classes to put in which packages? The question will be addressed later
  • Change to Package A may cause change to Package B. The circular dependency between Package A and B means that they must be treated as one package.
  • Domain Layer called Application-Logic Layer Application layer is different than Application-logic Layer The higher layers are more application specific
  • Note the use of the <<layer>> sterotype
  • The Database and LDAP are physical implementation components, not a layer in the logical architecture.
  • The next part of the course is all about the Domain layer
  • Transcript

    • 1. Object-Oriented Analysis and Design with UML2 – Part 1 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. Part1 Agenda
      • OO Analysis and Design Overview
      • UML Overview
      • Requirements Overview
      • Use Cases Overview
      • Basic OO Concepts
      • Architectural Analysis
    • 5. OO Analysis and Design Overview
      • What is Analysis?
        • Emphasis an investigation of the problem and requirements, rather than a solution
        • "Analysis" is a broad term, best qualified:
          • Requirements Analysis
          • Object-Oriented Analysis
      • What is Design?
        • Emphasizes a conceptual solution that fulfills the requirements rather its implementation.
        • the term is best qualified, as in object-oriented design or database design
    • 6. OO Analysis and Design Overview (Cont.)
      • do the right thing (analysis), and do the thing right (design)
      • The purpose of Analysis and Design:
        • Transform the requirements into a system design
    • 7. OO Analysis and Design Overview (Cont.)
      • What is Object-Oriented Analysis?
        • Finding and describing the concepts in the problem domain.
        • For example:
          • Flight Information System, some of the concepts: Plane , Flight , and Pilot .
          • Auto Rental Company, some of the concepts: Vehicle , Customer , and Reservation .
          • Payroll System, some of the concepts: Employee , PayCheck , and Timecard .
          • Course Registration System, some of the concepts: Student , Course , Registration , and Professor .
    • 8. OO Analysis and Design Overview (Cont.)
      • What is Object Oriented Design?
        • defining software objects, their responsibilities and how they collaborate to fulfill the requirements.
        • For Example:
          • Plane software object may have a getFlightHistory operation.
          • Vehicle software object may have a getStatus operation.
          • Employee software object may have a payCalculate operation.
          • Student software object may have a hasPrerequisites operation.
      • A critical ability in OO design is to skillfully assign responsibilities to software objects.
    • 9. OO Analysis and Design Overview (Cont.)
      • Analysis vs. Design
      • Analysis :
      • Focuses on understanding the problem
      • System structure
      • Small model of domain concepts
      • Design :
      • Focuses on understanding the solution
      • System structure
      • Responsibilities and attributes
      • A large model of system dynamic and static views
    • 10. OO Analysis and Design Overview (Cont.)
      • Input:
        • Use-Case Model
        • Glossary
        • Logical Architecture
      • Output:
        • Design Model
    • 11. OO Analysis and Design Overview (Cont.)
      • OOA&D Key Steps and Artifacts
        • Requirement Analysis -> Use Case Model
        • Architectural Analysis -> Logical Architecture
        • OO Analysis -> Analysis Model (Domain Model)
        • OO Design -> Design Model
    • 12. OO Analysis and Design Overview (Cont.)
    • 13. OO Analysis and Design Overview (Cont.)
      • Recommended References
        • Mastering Object-Oriented Analysis and Design with UML2.0, IBM Training Student Guide
    • 14.  
    • 15. Part1 Agenda
      • OO Analysis and Design Overview
      • UML Overview
      • Requirements Overview
      • Use Cases Overview
      • Basic OO Concepts
      • Architectural Analysis
    • 16. UML Overview
      • What is UML?
        • is a family of graphical notations, that help in specifying and constructing the artifacts of systems.
        • Is a unification of:
          • Booch Method by booch
          • OMT Method by Rumbaugh
          • Objectory method by Jacobson
    • 17. UML Overview (Cont.)
      • Why Modeling?
        • A model helps the software team to simplify the system.
        • A model helps the software team to communicate.
        • Specify the structure and behavior of a system.
        • It serves as a road map for a developer.
        • Document the decisions you have made.
    • 18. UML Overview (Cont.)
      • Forward engineering:
        • Draws diagrams before write code
      • Reverse Engineering:
        • Builds diagrams from existing code.
      • Three Ways to Apply UML
        • UML as Sketch: incomplete diagrams, using paper or whiteboard.
        • UML as Blueprint: complete diagrams, using UML Tool.
        • UML as Programming Language: complete executable diagrams.
    • 19. UML Overview (Cont.)
      • UML Perspectives:
        • Conceptual Perspectives: diagrams in this perspective describe concepts of the domain (real-world)
        • Software perspective: diagrams in this perspective describe software abstractions
      • The Meaning of “UML Class” in Different Perspectives
        • Class in the Domain Model (conceptual perspective) means conceptual class
        • Class in the Design Model (Software perspective) means Software class
    • 20. UML Overview (Cont.)
      • Modeling Types:
        • Dynamic Modeling : such as sequence diagram, help design the logic, the behavior of method bodies.
          • what messages to send, and to whom, and in what order.
        • Static Modeling : such as class diagram, help design the definition of the elements, and method signatures.
    • 21.  
    • 22. UML Overview (Cont.)
      • Dynamic Modeling is the most challenging, interesting, useful design work.
      • Spend significant time doing interaction diagrams not just class diagrams.
      • During dynamic modeling, we apply responsibility-driven design .
    • 23. UML Overview (Cont.)
      • Dynamic Modeling Example
    • 24. UML Overview (Cont.)
      • Static Modeling Example
    • 25. UML Overview (Cont.)
      • The relationship between interaction diagram and class diagram
    • 26. UML Overview (Cont.)
      • Recommended References:
        • UML Distilled: A Brief Guide to the Standard Object Modeling Language, Third Edition, By Martin Fowler
        • Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition, By Craig Larman
        • Mastering Object-Oriented Analysis and Design with UML2.0, IBM Training Student Guide
    • 27.  
    • 28. Part1 Agenda
      • OO Analysis and Design Overview
      • UML Overview
      • Requirements Overview
      • Use Cases Overview
      • Basic OO Concepts
      • Architectural Analysis
    • 29. Requirements Overview
      • Requirements are characteristics , capabilities , qualities and conditions to which the system must conform.
      • Requirements Analysis is a set of activities to find , communicate , and remember what is really needed.
      • OOA&D gets its primary input from requirements analysis.
      • The purpose of Requirements Analysis:
        • To establish agreement with the stakeholders.
        • To define the boundaries of the system.
        • To provide the developers with a better understanding of the system
        • To provide a basis for the planning and estimating.
    • 30. Requirements Overview (Cont.)
      • Requirements Categorization
        • Functionality : features, capabilities
        • Usability : human factors, help, manual.
        • Reliability : frequency of failure, recoverability, predictability.
        • Performance : response times, throughput, availability.
        • Supportability : adaptability, maintainability.
    • 31. Requirements Overview (Cont.)
      • Requirements Analysis Artifacts (Outputs):
        • Use-Case Model : captures the functional requirements
        • Supplementary Specification : captures the non-functional requirements
        • Glossary : define noteworthy terms, validation rules, and acceptable values.
    • 32. Requirements Overview (Cont.)
      • Recommended References:
          • Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition, By Craig Larman
          • Mastering Object-Oriented Analysis and Design with UML2.0, IBM Training Student Guide
          • Head First Object Oriented Analysis and Design
    • 33.  
    • 34. Part1 Agenda
      • OO Analysis and Design Overview
      • UML Overview
      • Requirements Overview
      • Use Cases Overview
      • Basic OO Concepts
      • Architectural Analysis
    • 35. Use Case Overview We are Here
    • 36. Use Case Overview (Cont.)
      • Actor is something with behavior, such as a person (identified by role), computer system, or organization.
        • for example, a Student.
    • 37. Use Case Overview (Cont.)
      • System behavior is the result of the interactions between actors and the system (Clear Value).
        • Functionality Requirements is the set of system behaviors.
      • For example:
        • In case of Auto Rental Company:
          • Reserve a Vehicle, Cancel a Reservation, View Customer Profile.
        • In case of Point of Sale System:
          • Process Sale, Handle Cash Payment, Handle Returns.
        • In case of Payroll System:
          • Create Employee, Maintain Timecard, Run Payroll.
        • In case of Course Registration System:
          • Register for Course, Maintain Student Information, Submit Grades.
    • 38. Use Case Overview (Cont.)
      • Scenario: is a sequence of actions and interactions between actors and the system.
      • Different sequences of actions (scenarios) can happen, depending on the requests made and conditions surrounding the requests.
    • 39. Use Case Overview (Cont.)
      • Use Case is a set of scenarios that yields a system behavior.
      • Use Cases are functional requirements that indicate what the system will do.
      • Nothing object-oriented about use cases.
    • 40. Use Case Overview (Cont.)
      • Example:
      • Process Sale:
      • A customer arrives at a checkout with items to purchase.
      • The cashier starts a new sale.
      • The cashier enters item identifier.
      • The system records line item and presents a running total and line-item details.
      • 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.
    • 41. Use Case Overview (Cont.)
        • Use Case Flow of Events:
          • Has one normal basic flow of actions (happy scenario)
          • Several alternative flows of actions
      • Each flow of actions called scenario
      • Example:
        • Basic Flow: Successfully purchasing items.
        • Alternative Flow: Failing to purchase items because of a credit payment denial
    • 42. Use Case Overview (Cont.)
        • Why Use Cases:
          • Because they are simple, it possible for domain expert to participate in writing them.
          • Use cases can be a basis for writing the system user guide.
          • Use cases emphasize the user goals and perspective.
            • Who is using the system?
            • What are their goals?
    • 43. Use Case Overview (Cont.)
        • Use Case Model
          • is the set of all written use cases.
        • Use Case Model may also include:
          • Use Case Diagram
          • Activity Diagrams
          • System Sequence Diagrams
    • 44. Use Case Overview (Cont.)
      • Use Case Examples:
        • Example 1: Auto Rental System - Reserve a Vehicle
        • This use case begins when a customer indicates he wishes to make a reservation for a rental car.
        • The system prompts the customer for the pickup and return locations of the reservation, as well as the pickup and return dates and times. The customer indicates the desired locations and dates.
        • The system prompts for the type of vehicle the customer desires. The customer indicates the vehicle type.
    • 45. Use Case Overview (Cont.)
        • The system presents all matching vehicles available at the pickup location for the selected date and time. If the customer requests detail information on a particular vehicle, the system presents this information to the customer.
        • If the customer selects a vehicle for rental, the system prompts for information identifying the customer (full name, telephone number, email address for confirmation, etc.). The customer provides the required information.
        • The system presents information on protection products (such as damage waiver, personal accident insurance) and asks the customer to accept or decline each product. The customer indicates his choices.
    • 46. Use Case Overview (Cont.)
        • If the customer indicates "accept reservation," the system informs the customer that the reservation has been completed, and presents the customer a reservation confirmation.
        • This use case ends when the reservation confirmation has been presented to the customer.
    • 47. Use Case Overview (Cont.)
      • Use Case Examples:
        • Example 2: Payroll System – Run Payroll – Basic Flow
        • The use case begins when it’s time to run payroll, the payroll runs automatically every last working day of the month.
        • The system retrieves all the employees.
        • The system calculates the pay using the entered timecard (See Maintain Timecard use case).
        • If the payment delivery is mail or pick-up, the system prints a paycheck.
        • If the payment delivery is direct deposit, the system creates a bank transaction and sends it to the bank system for processing.
        • The use case ends when all employees receiving pay.
    • 48. Use Case Overview (Cont.)
        • Payroll System – Run Payroll – Alternative Flow
        • Bank System Unavailable:
        • If the Bank system is down, the system will attempt to send the bank transaction again after a specified period. The system will continue to attempt to re-transmit until the Bank System becomes available.
    • 49. Use Case Overview (Cont.)
      • Use Case Examples
        • Example 3: Flight Information System – Request Available Flights – Main Path
        • This use case begins when a customer indicates he wishes to request available flights
        • The system prompts the customer for the origination city, destination city, type of flight (one-way or round trip), departure date, and return date. The customer fills the information.
        • The system shows list of flights that met customer’s criteria.
    • 50. Use Case Overview (Cont.)
        • Flight Information System – Request Available Flights – Alternative Paths:
        • 3.A The customer entered an invalid data, such as the departure date is greater than the return date, the system will display error message “Return date must be greater than departure date”.
        • 3.B The customer entered a valid data but the flight can’t be found, the system will display error message “No flights are available”
    • 51. Use Case Overview (Cont.)
      • Use Case Examples
        • Example 4: ATM Machine – Withdraw Cash – Main Flow
        • The use case begins when the customer inserts his ATM card into the ATM machine.
        • The system validates the ATM card and prompts the customer to enter PIN code.
        • The customer enters the PIN and selects.
        • The system validates the PIN entered and displays the Options Menu Screen.
        • The customer selects the ‘Cash Withdrawal’ option from the Options Menu.
    • 52. Use Case Overview (Cont.)
        • The system prompts the customer to enter the amount of cash that he or she wants to withdraw
        • The customer enters a cash amount and selects the ‘Submit’ option on the Cash Withdrawal Screen.
        • The system validates the amount entered; asks the bank system to check the account balance.
        • The system ejects the ATM card, provides the cash and requests to update the account balance of the customer in the system
    • 53. Use Case Overview (Cont.)
        • ATM Machine – Withdraw Cash – Alternative Flows
        • *.A If the customer presses the ‘Cancel’ button at any time, the system cancels the transaction and returns the ATM card to the customer.
        • 2.A System detects that the ATM card is not compatible with the ATM machine or has been damaged, The system rejects the ATM card and displays an error message.
        • 4.A The PIN that the customer has entered is not valid
        • 1. The system prompts the customer to enter a valid PIN
        • 2. The customer enters his or her PIN.
        • 3. The system validates the PIN, displays the ‘Options’ menu, and continues from step 5 (Main Success Scenario).
    • 54. Use Case Overview (Cont.)
          • ATM Machine – Withdraw Cash – Alternative Flows
          • 8.A the system detected that the amount entered is greater than the account balance, the system shows an error message and prompts the customer to enter new amount and the system returns to step 6 of the main scenario
    • 55. Use Case Overview (Cont.)
      • Applying UML:
        • Review: Use case is a set of interactions and activities .
        • For use cases that describe complex flow of actions, Activity Diagram can be applied to visualize the use case flow.
        • For use cases that describe complex interactions with the actor, System Sequence Diagram (SSD) can be applied to visualize the system operations.
    • 56. Use Case Overview (Cont.)
      • Activity Diagram is a flow of chart, showing flow of control from one activity to another.
    • 57. Use Case Overview (Cont.)
      • Activity Diagram:
        • The following shows an example on Activity Diagrams for POS System – Process Sale Use Case
    • 58.  
    • 59.  
    • 60. Use Case Overview (Cont.)
      • Applying UML:
        • The following shows an example on how to build an Activity Diagram from Use Case (ATM Machine – Withdraw Cash Use Case)
    • 61. Use Case Overview (Cont.)
        • ATM Machine – Withdraw Cash Use Case – Main Scenario
        • The use case begins when the customer inserts his ATM card into the ATM machine.
        • The system validates the ATM card and prompts the customer to enter PIN code.
      Customer Inserts ATM Card System Validate the ATM Card ATM Card System prompts for PIN
    • 62. Use Case Overview (Cont.)
        • The customer enters the PIN .
        • The system validates the PIN entered and displays the Options Menu Screen .
      Customer enters PIN PIN System Validates the PIN System displays Options
    • 63. Use Case Overview (Cont.)
        • The customer selects the ‘Cash Withdrawal’ option from the Options Menu.
        • The system prompts the customer to enter the amount of cash.
        • The customer enters a cash amount
      Customer selects ‘Cash Withdraw’ System prompts for amount Customer enters amount Amount
    • 64. Use Case Overview (Cont.)
        • The system validates the amount entered ; asks the bank system to check the account balance .
      System submit account balance check Bank validates the amount
    • 65. Use Case Overview (Cont.)
        • The system ejects the ATM card , provides the cash and requests to update the account balance of the customer in the bank system.
      System ejects ATM Card System provides cash System submits update account Cash Bank updates account balance
    • 66.  
    • 67. Use Case Overview (Cont.)
      • Exercise:
        • The previous activity diagram visualizes the main path of the use case; update the activity diagram to visualize the alternative paths.
    • 68. Use Case Overview (Cont.)
      • System Sequence Diagram, for a particular use case, shows:
        • The external actors that interact with the system.
        • The system as a black box.
        • The system events that the actors generate (Interaction).
    • 69. Use Case Overview (Cont.)
      • Applying UML:
        • The following shows an example on System Sequence Diagrams for ATM Machine – Withdraw Cash
    • 70.  
    • 71. Use Case Overview (Cont.)
      • Cash only Process Sale Use case:
        • A customer arrives at a checkout with items to purchase.
        • The cashier starts a new sale .
        • The cashier enters item identifier .
        • The system records line item and presents a running total and line-item details .
        • 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 change due and receipt from the system and then leaves with the items.
    • 72. Use Case Overview (Cont.)
      • The following shows how to map a use case to an SSD
    • 73. Use Case Overview (Cont.)
      • Exercise:
        • Select one of the following use cases and visualize its interactions with the actors using System Sequence Diagram (SSD);
          • Auto Rental System - Reserve a Vehicle
          • Payroll System - Run Payroll
          • Flight Information System – Request Available Flights
          • ATM Machine – Withdraw Cash
    • 74. Use Case Overview (Cont.)
      • Use Case Diagram:
        • The UML provides use case diagram notation to illustrate
          • The system boundaries.
          • The names of use cases.
          • The name of actors.
          • The relationships between the use cases and actors.
    • 75. Use Case Overview (Cont.)
      • Example 1: POS System
    • 76. Use Case Overview (Cont.)
      • Use Case Diagram Guidelines:
    • 77.  
    • 78. Use Case Overview (Cont.)
    • 79. Use Case Overview (Cont.)
      • Exercise:
        • Create a use case diagram for your current project.
    • 80. Use Case Overview (Cont.)
      • Use Case Modeling:
        • Starts by requirement list (Input).
        • Find system behaviors list
        • Find actors
        • Draw use case diagram
        • For each behavior write a use case
        • For complex use cases draw at least one activity diagram
        • For complex use cases draw at least one SSD
        • Then collect (Use case diagram, use cases, activity diagrams and SSDs) in one Use-Case Model (Output).
    • 81.  
    • 82. Use Case Overview (Cont.)
        • Recommended References:
          • Writing Effective Use Cases, By Cockburn
          • Mastering Object-Oriented Analysis and Design with UML2.0, IBM Training Student Guide
          • Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition, By Craig Larman
          • UML Distilled: A Brief Guide to the Standard Object Modeling Language, Third Edition, By Martin Fowler
    • 83.  
    • 84. Part1 Agenda
      • OO Analysis and Design Overview
      • UML Overview
      • Requirements Overview
      • Use Cases Overview
      • Basic OO Concepts
      • Architectural Analysis
    • 85. Basic OO Concepts
      • OO Basic Principles
      • Abstraction
      • Encapsulation
      • Modularity
      • Hierarchy
      • Class
      • Object
      • Object Identity
      • Operation vs. Behavior
      • Attribute vs. Property
      • Object State vs. Structure
      • Association
      • Unary Association
      • Navigability
      • Multiplicity
      • Association vs. Dependency
      • Aggregation vs. Composition
      • Link vs. Association
      • Usage
      • Generalization vs. Inheritance
      • Realization vs. Generalization
      • Visibility vs. Navigability
    • 86. Basic OO Concepts
      • OO Basic Principles:
        • Abstraction
        • Encapsulation
        • Modularity
        • Hierarchy
    • 87. Basic OO Concepts
      • Abstraction:
        • focuses on the essential characteristics of some object, relative to the perspective of the viewer .
      • Key Concepts:
        • Concentrating only on essential characteristics,
          • Allows complexity to be more easily managed
        • Abstraction is relative to the perspective of the viewer
          • Many different views of the same object are possible
    • 88. Basic OO Concepts (Cont.)
    • 89. Basic OO Concepts (Cont.)
      • Examples on Abstraction
    • 90. Basic OO Concepts (Cont.)
      • Encapsulation:
        • Is the process of grouping the elements of an abstraction that form its structure and behavior and hiding them from the client using a contractual interface .
      • Key Concepts:
        • Packaging structure and behavior in one unit.
          • Make abstractions more independent
        • Exposing an interface:
          • Hides complexity of the abstraction internal implementation from the clients
        • It was called information hiding (data and implementation hiding)
    • 91. Basic OO Concepts (Cont.)
      • Key Concepts (Cont.)
        • Encapsulation offers two kinds of security
          • Protects the internal state from being changed by outside users
          • Changes can be done to the behavior implementation without affecting other objects
    • 92. Basic OO Concepts (Cont.)
    • 93. Basic OO Concepts (Cont.)
      • Modularity: it is the process of breaking up a complex system into small, self-contained pieces that can be understood and managed easily.
      • Modularity packages abstractions into discrete units.
      • Key Concepts:
        • Cohesive modules (performing a single type of tasks)
          • Makes modules more reusable
        • Loosely coupled modules (highly independent)
          • Makes modules more robust and maintainable
    • 94. Basic OO Concepts (Cont.)
    • 95. Basic OO Concepts (Cont.)
      • Example of Modularity
    • 96. Basic OO Concepts (Cont.)
      • Hierarchy: is a ranking or ordering of abstractions
      • Hierarchies simplify our understanding of the problem, by making it easy to recognize similarities and differences.
        • For example:
          • botany organizes plants into families
          • Chemistry organizes elements into a periodic table.
      • Hierarchy is not a functional decomposition (this is modularity)
    • 97.  
    • 98. Basic OO Concepts (Cont.)
      • Example of Hierarchy:
    • 99. Basic OO Concepts (Cont.)
    • 100. Basic OO Concepts (Cont.)
      • OO Principles Summary:
        • Abstraction reduces the complexity by discarding irrelevant details (properties and behavior).
        • Encapsulation simplifies the abstraction complexity by hiding the inside view of our abstractions.
        • Modularity helps also to simplify the system complexity by packaging the logically related abstractions.
        • Hierarchy helps also to simplify the system complexity by distributing the abstractions on different levels
          • Identify the commonalities between the abstractions at the same level.
          • Commonalities between abstractions can lead to identify more generic abstractions that represent these commonalities.
    • 101. Basic OO Concepts (Cont.)
      • Object represent an entity with a well-defined boundary and identity that encapsulates state and behavior .
    • 102. Basic OO Concepts (Cont.)
      • Structure of an object encompasses all of the properties of the object.
      • State of an object encompasses all of the properties of the object plus the current values of each of these properties.
        • Properties of an object are fixed (static).
        • Property values of an object usually change (usually dynamic)
        • Examples:
          • Property with dynamic value: employee salary
          • Property with static value: employee number
    • 103. Basic OO Concepts (Cont.)
      • Exercise:
        • For a vending machine,
          • identify at least two properties
          • Identify a property with static value
          • Identify a property with dynamic value
          • Represent them in UML
    • 104. Basic OO Concepts (Cont.)
      • Behavior is how an object acts and reacts in terms of:
        • its state changes.
        • Message passing.
      • Example behaviors for employee Haitham
        • Updating the value of the property salary
        • Assigning a task to Haitham
      • In other words, the behavior of an object represents its outwardly visible activity .
      • An action that updates any of the object’s property values causes a change of the object’s state.
    • 105. Basic OO Concepts (Cont.)
      • Abstractions can be represented in OO P as classes .
      • Class is an abstraction in that it
        • Emphasis relevant characteristics.
        • Suppresses other characteristics.
    • 106. Basic OO Concepts (Cont.)
      • Classes are more than representation for abstractions
        • A class is a description of a set of objects that share
          • a common structure
          • a common behavior
        • A class serves as a template for creating objects.
        • The objects created from a class are called the instances of the class.
        • The class is an encapsulation of;
            • A set of attributes (the objects structure description)
            • A set of operations (the objects behavior description)
      • The class is the static description; the object is a run time instance of that class.
    • 107. Basic OO Concepts (Cont.)
      • An Attribute describes the range of values that instances of a property may hold.
      • An attribute has a type that defines the type of its instances
    • 108. Basic OO Concepts (Cont.)
      • Operation is the description of a service that can be requested from any object of the class to affect behavior .
      • An operation has s signature, which restrict the possible parameters.
    • 109. Basic OO Concepts (Cont.)
      • An operation can be:
        • Question/Selector : accesses the state of an object but does not alter the state.
        • Modifier/Command: alters the state of an object.
        • Iterator : permits all parts of an object to be accessed in some well-defined order.
        • Constructor : creates and/or initializes its state.
        • Destructor : frees the object status and/or destroys the object itself.
    • 110. Basic OO Concepts (Cont.)
      • Operation Example:
    • 111. Basic OO Concepts (Cont.)
      • Modeling Objects in UML
    • 112. Basic OO Concepts (Cont.)
      • Relationships between Classes:
        • Association (General relationship)
          • Aggregation (Special Type of Association)
          • Composition (Special Type of Association)
        • Dependency (General relationship)
          • Usage (Special Type of Dependency)
          • Generalization (Special Type of Dependency)
          • Realization (Special Type of Dependency)
    • 113. Basic OO Concepts (Cont.)
      • Association : is a structural relationship , specifying that objects of a class are linked to other objects.
      • Structural Relationship means that the relationship is part of the object structure.
      • Link is an instance of association.
      • In Association, the messages may flow in either direction or in both directions across a link.
      • Bi-directional associations (between classes) need two links (between the objects) to represent the association.
    • 114. Basic OO Concepts (Cont.)
      • Most Associations are binary associations (between two classes)
      • Unary association : when a class has an association to itself.
      • Unary association means that one instance of a class has links to another instance of the same class.
    • 115. Basic OO Concepts (Cont.)
      • Association Navigability :
        • Indicates that it is possible to navigate from an associating class to the target class using the association .
          • The Navigability between classes implies that there is a visibility between their instances .
    • 116. Basic OO Concepts (Cont.)
    • 117. Basic OO Concepts (Cont.)
      • Association Multiplicity :
        • Multiplicity is the number of instances of a class relates to ONE instance of another class.
        • For each association, there are two multiplicity decisions to make, one for each end of the association.
    • 118. Basic OO Concepts (Cont.)
      • In below:
        • For each instance of professor, many Course instances may be taught.
        • For each instance of Course, there may be either one or zero Professor instance as the instructor.
    • 119. Basic OO Concepts (Cont.)
      • Multiplicity Indicators:
      Unspecified Exactly One 1 Zero or More 0..* Zero or More * One or More 1..* Zero or one (optional) 0..1 Specified Range 2..4 Multiple, Disjoint Ranges 2, 4..6 Multiple 2, 4, 6
    • 120. Basic OO Concepts (Cont.)
      • Aggregation :
        • Is a special type of the association
        • is the same as the association with the exception that the aggregation can’t be bi-directional.
        • Aggregation is a typical whole/part relationship.
        • Aggregation is a weak form of association where the part is independent of the whole (aggregate)
          • The same instance of part could be included in several whole instances (shared parts)
          • If the whole instance is destroyed, the part instances may still exist
    • 121. Basic OO Concepts (Cont.)
      • Aggregation Example - In below:
        • One instance of Company can have one or more instances of Employee.
        • One instance of Employee can be working in one or more companies at the same time.
    • 122. Basic OO Concepts (Cont.)
      • Composition :
        • Is a special type of the association
        • is exactly the same as the aggregation with the exception that the life time of the part is controlled by the whole.
        • Composition is a strong form of aggregation.
          • The instance of part can be included in one and only one instance of the whole.
          • If the whole instance is deleted, then the part instances must be deleted too.
    • 123. Basic OO Concepts (Cont.)
      • Composition Example - In below:
        • One instance of Company may contain zero or more instances of Departments.
        • One instance of Department can be part of one and only one instance of Company.
        • The Department instance can’t live without its company
    • 124. Basic OO Concepts (Cont.)
      • UML Structured Class:
        • Because the aggregation and composition are structural relationships we can represent them using UML Structured class.
        • UML Structured class are usually used to describe the internal structure of components and systems.
        • UML Structured class can be used to describe the internal structure of an instance with complex internal structure (complex aggregations and compositions).
        • Structured class contains parts that form the class structure.
        • The parts themselves may also be structured classes.
    • 125.
      • Structured Class Example:
      Whole shared: Part2[1..*] comp: Part1[0..*] Basic OO Concepts (Cont.)
    • 126. Basic OO Concepts (Cont.) Bank System :External Accounting sub-system :Logging sub-system :Loan sub-subsystem
    • 127. Basic OO Concepts (Cont.)
      • Dependency Relationship:
        •   is a relationship in which changes to one model element impact another model element.
        • Non-structural relationship (that the relationship is not part of the client object structure)
        • Dependency Types:
          • Usage
          • Generalization
          • Realization
    • 128. Basic OO Concepts (Cont.)
      • Usage Dependency:
        • “ Usage” usually called dependency which leads to a confusion.
        • “ Usage” dependency is a weaker form of relationship.
        • “ Usage” dependency shows a relationship between a client/consumer and supplier/provider.
        • The Usage relationship is not part of the client object structure.
        • Indicates that the instance of the client class temporarily uses an instance of the supplier.
    • 129. Basic OO Concepts (Cont.)
      • Usual UML keywords of Usage:
        • «use», «create», «call», «instantiate», «send»
    • 130. Basic OO Concepts (Cont.)
      • Generalization/Specialization
        • Is a relationship among classes where one class shares the structure/behavior of one or more classes.
        • Generalization defines a hierarchy of abstractions in which a subclass inherits from one or more super classes.
        • The objects of the subclasses (specialized classes) are substitutable for objects of the super class (generalized classes).
        • Sometimes called “is a” relationship.
      • Inheritance is a mechanism to implement the generalization relationship.
    • 131. Basic OO Concepts (Cont.) The hierarchy help to find the generalization
    • 132. Basic OO Concepts (Cont.)
      • Realization
        • One classifier serves as the contract that the other classifier agrees to carry out.
        • One classifier supplies/provides (supplier) the contract and the other realizes it (client).
        • The contract means the set of operations signatures.
        • It is not true generalization, as only the contract is inherited.
        • Several clients can realize the behavior of a single supplier.
      Supplier Client
    • 133. Basic OO Concepts (Cont.)
      • Implementation (Interface Realization):
        • Is a specialized type of realization relationship between a classifier (client/implementation) and an interface (supplier)
        • The implementation relationship specifies that the realizing classifier must conform to the contract that the interface provides.
    • 134. Basic OO Concepts (Cont.)
      • Modeling Implementation in UML
        • Canonical Form:
        • Elided Form
    • 135. Basic OO Concepts (Cont.)
      • Interface:
        • A declaration of a coherent set of public features and obligations
        • An interface specifies a contract between providers and consumers of services.
        • Examples of Interfaces:
          • Provided Interface – describe the set of services the classifier offers to its consumers.
          • Required Interface – describes the set of services the classifier requires from its other classifiers
    • 136. Basic OO Concepts (Cont.)
      • Provided Interface
    • 137. Basic OO Concepts (Cont.)
      • Required Interface
      Interface1
    • 138. Basic OO Concepts (Cont.)
      • Connecting Interfaces
      Interface1
    • 139. Basic OO Concepts (Cont.)
      • Polymorphism
        • The ability to hide many different implementations behind a single interface.
        • Every implementation of an interface must fulfill the requirements of that interface.
    • 140. Basic OO Concepts (Cont.)
      • Relationship Visibility
        • is the ability of one object to see or have reference to another.
        • For an object A to send a message to an object B, B must be visible to A.
        • Object B is visible to object A if B class and A class has any of the following relationships:
          • Association (Aggregation and Composition)
          • Usage Dependency
    • 141. Basic OO Concepts (Cont.)
      • Relationship Visibility Levels:
        • Attribute Visibility:
          • Exists from A to B when B is an attribute of A
          • It is a relatively permanent visibility because it persists as long as A and B exist.
          • It implies that the relationship between A and B classes is Association/Aggregation or Composition.
        • Parameter Visibility:
          • Exists from A to B when B is a parameter to a method of A.
          • temporary visibility; within the scope of the method.
    • 142. Basic OO Concepts (Cont.)
        • Local Visibility:
          • Exists from A to B when B is declared as local variable within a method of A.
        • Global Visibility:
          • Exists from A to B when B is global to A.
          • It is not applicable in java.
          • The preferred method to achieve global visibility is to use the Singleton pattern.
    • 143. Basic OO Concepts (Cont.)
      • Recommended References
        • Object-Oriented Analysis and Design With Applications, By Grady Booch
        • Mastering Object-Oriented Analysis and Design with UML2.0, IBM Training Student Guide
        • UML Distilled: A Brief Guide to the Standard Object Modeling Language, Third Edition, By Martin Fowler
        • Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition, By Craig Larman
        • http ://publib.boulder.ibm.com/infocenter/rtnlhelp/v6r0m0/index.jsp?topic=% 2Fcom.ibm.xtools.modeler.doc%2Ftopics%2Fcdepend.html
    • 144.  
    • 145. Part1 Agenda
      • OO Analysis and Design Overview
      • UML Overview
      • Requirements Overview
      • Use Cases Overview
      • Basic OO Concepts
      • Architectural Analysis
    • 146. Architectural Analysis Now We are Here We were Here
    • 147. Architectural Analysis (cont.)
      • What is Architecture: The “4+1 View” Model
      Logical View Process View Implementation View Deployment View Designers Structure System Engineers System Topology, installation, Comm. Programmers Software Management Integrators Performance, Scalability, Throughput Use Case View
    • 148. Architectural Analysis (cont.)
      • In the Architectural Analysis step the software architect focuses on the Logical Architecture.
      • Logical Architecture: is the large scale organization of the software classes into packages, subsystems, and layers .
    • 149. Architectural Analysis (cont.)
      • Package:
        • Is a general-purpose mechanism for organizing elements into groups.
        • It is a model element that can contain other model elements.
        • Packages can also be members of other packages
        • In UML, packages are shown with a tabbed folder
    • 150. Architectural Analysis (cont.)
      • Package Relationships: Dependency
        • Packages can be related to one another using a dependency relationship.
        • Dependency relationship between packages indicates that the elements of the Client have a reference to elements in the Supplier
    • 151. Architectural Analysis (cont.)
      • Package Dependency Implications
        • Changes to the supplier may affect the client.
        • The client cannot be reused independently because it depends on the supplier.
        • Packages allows its classes to be public or private.
        • A Public class is part of the interface of the package and can be used by classes in other packages.
        • A private class is hidden.
        • A useful technique here is to reduce the package interface by:
          • Exploring a small subset of the public classes, or
          • Using the façade design pattern:
            • You can give all the classes private visibility.
            • Add an extra public class for the public behavior (Façade design pattern).
    • 152. Architectural Analysis (cont.)
      • Avoiding Circular Dependencies
      Package Hierarchy should be acyclic Circular dependencies make it impossible To reuse one package without the other
    • 153.
      • Subsystem and Component
    • 154. Architectural Analysis (cont.)
      • Patterns:
        • Provides a common solution to a common problem
        • In software development there are many types of patterns:
          • Architectural Patterns
          • OO Analysis Patterns
          • OO Design Patterns
    • 155. Architectural Analysis (cont.)
      • What is an Architectural Pattern?
        • It provides a set of:
          • predefined sub-systems,
          • specifies their responsibilities,
          • and includes rules for organizing the relationships.
        • Architectural Patterns:
          • Layers
          • MVC
          • Pipes and filters
          • Blackboard
    • 156. Architectural Analysis (cont.)
      • Layers:
        • Layering represents an order grouping of functionality, with:
          • The application specific functions located in the upper layers.
          • The functionality that spans application domains in the middle layers.
          • The functionality specific to the deployment environment at the lower layers
        • Upper layers use services of the lower layers, but not vice versa.
        • In a strict layered architecture , a layer only calls upon the services of the layer directly below it.
          • This design is common in network protocol stacks,
        • In a relaxed layered architecture , higher layer calls upon several lower layers.
          • This design is common in information systems.
    • 157.
      • Typical Layering
    • 158. Architectural Analysis (cont.)
      • Layering Considerations:
        • Level of abstractions:
          • Group elements at the same level of abstraction.
        • Separation of concerns
          • Group like things together.
          • Separate disparate things.
          • The responsibilities of the objects in a layer should be strongly related to each other (High Cohesion)
        • Resiliency:
          • Loose Coupling.
          • Concentrate on encapsulating what change.
          • User Interface, Business Rules, and retained data tend to have a high potential for change.
    • 159. Architectural Analysis (cont.)
      • Applying UML:
    • 160. Architectural Analysis (cont.)
      • Applying UML:
        • Don’t show external resources as the bottom layer
    • 161. Architectural Analysis (cont.)
      • What’s the Connection Between SSDs and Layers
    • 162. Basic OO Concepts (Cont.)
      • Recommended References
        • Mastering Object-Oriented Analysis and Design with UML2.0, IBM Training Student Guide
        • UML Distilled: A Brief Guide to the Standard Object Modeling Language, Third Edition, By Martin Fowler
        • Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition, By Craig Larman
    • 163. References
      • UML Distilled: A Brief Guide to the Standard Object Modeling Language, Third Edition, By Martin Fowler
      • Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition, By Craig Larman
      • Head First Design Patterns
      • Design Patterns: Elements of Reusable Object-Oriented Software, By Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
      • Writing Effective Use Cases, By Cockburn
    • 164. References (Cont.)
      • Analysis Patterns: Reusable Object Models, By Martin Fowler
      • Object Design: Roles, Responsibilities, and Collaborations, By Wirfs-Brock
      • Mastering Object-Oriented Analysis and Design with UML2.0, IBM Training Student Guide

    ×