Object Oriented Analysis and Design with UML2 part1

Object-Oriented Analysis and Design with UML2 – Part 1 Presented By Haitham Raik

Agenda Part 1: OO Analysis and Design Overview UML Overview Requirements Overview Use Cases Overview Basic OO Concepts Architectural Analysis

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

Part1 Agenda OO Analysis and Design Overview UML Overview Requirements Overview Use Cases Overview Basic OO Concepts Architectural Analysis

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

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

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 .

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.

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

OO Analysis and Design Overview (Cont.) Input: Use-Case Model Glossary Logical Architecture Output: Design Model

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

OO Analysis and Design Overview (Cont.)

OO Analysis and Design Overview (Cont.) Recommended References Mastering Object-Oriented Analysis and Design with UML2.0, IBM Training Student Guide

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

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.

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.

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

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.

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 .

UML Overview (Cont.) Dynamic Modeling Example

UML Overview (Cont.) Static Modeling Example

UML Overview (Cont.) The relationship between interaction diagram and class diagram

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

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.

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.

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.

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

Use Case Overview (Cont.) Actor is something with behavior, such as a person (identified by role), computer system, or organization. for example, a Student.

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.

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.

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.

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.

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

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?

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

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.

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.

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.

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.

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.

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.

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”

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.

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

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).

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

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.

Use Case Overview (Cont.) Activity Diagram is a flow of chart, showing flow of control from one activity to another.

Use Case Overview (Cont.) Activity Diagram: The following shows an example on Activity Diagrams for POS System – Process Sale Use Case

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)

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

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

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

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

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

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.

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).

Use Case Overview (Cont.) Applying UML: The following shows an example on System Sequence Diagrams for ATM Machine – Withdraw Cash

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.

Use Case Overview (Cont.) The following shows how to map a use case to an SSD

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

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.

Use Case Overview (Cont.) Example 1: POS System

Use Case Overview (Cont.) Use Case Diagram Guidelines:

Use Case Overview (Cont.) Exercise: Create a use case diagram for your current project.

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).

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

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

Basic OO Concepts OO Basic Principles: Abstraction Encapsulation Modularity Hierarchy

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

Basic OO Concepts (Cont.) Examples on Abstraction

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)

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

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

Basic OO Concepts (Cont.) Example of Modularity

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)

Basic OO Concepts (Cont.) Example of Hierarchy:

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.

Basic OO Concepts (Cont.) Object represent an entity with a well-defined boundary and identity that encapsulates state and behavior .

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

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

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.

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.

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.

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

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.

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.

Basic OO Concepts (Cont.) Operation Example:

Basic OO Concepts (Cont.) Modeling Objects in UML

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)

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.

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.

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 .

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.

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.

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

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

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.

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.

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

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.

Structured Class Example: Whole shared: Part2[1..*] comp: Part1[0..*] Basic OO Concepts (Cont.)

Basic OO Concepts (Cont.) Bank System :External Accounting sub-system :Logging sub-system :Loan sub-subsystem

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

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.

Basic OO Concepts (Cont.) Usual UML keywords of Usage: «use», «create», «call», «instantiate», «send»

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.

Basic OO Concepts (Cont.) The hierarchy help to find the generalization

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

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.

Basic OO Concepts (Cont.) Modeling Implementation in UML Canonical Form: Elided Form

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

Basic OO Concepts (Cont.) Provided Interface

Basic OO Concepts (Cont.) Required Interface Interface1

Basic OO Concepts (Cont.) Connecting Interfaces Interface1

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.

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

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.

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.

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

Architectural Analysis Now We are Here We were Here

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

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 .

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

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

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).

Architectural Analysis (cont.) Avoiding Circular Dependencies Package Hierarchy should be acyclic Circular dependencies make it impossible To reuse one package without the other

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

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

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.

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.

Architectural Analysis (cont.) Applying UML:

Architectural Analysis (cont.) Applying UML: Don’t show external resources as the bottom layer

Architectural Analysis (cont.) What’s the Connection Between SSDs and Layers

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

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

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

Object Oriented Analysis and Design with UML2 part1

In this document