DEV475 Mastering Object-Oriented Analysis and Design with UML 2.0 Student Guide, Volume 2

Transcription

1 IBM Rational University DEV475 Mastering Object-Oriented Analysis and Design with UML 2.0 Student Guide, Volume 2 DEV475 Mastering Object-Oriented Analysis and Design with UML 2.0 Student Guide, Volume 2 Part No.

2 IBM Corporation Rational University DEV475 Mastering Object-Oriented Analysis and Design with UML 2.0 Student Manual, Volume 2 Version June 2004 Copyright International Business Machines Corporation, All rights reserved. This document may not be reproduced in whole or in part without the prior written permission of IBM. The contents of this manual and the associated software are the property of Rational Software and/or its licensors, and are protected by United States copyright laws, patent laws, and various international treaties. For additional copies of this manual or software, please contact Rational Software. IBM and the IBM logo are trademarks or registered trademarks of IBM Corporation, in the United States, other countries or both. Rational, the Rational logo, ClearQuest, ClearCase, ClearCase LT, ClearCase MultiSite, Unified Change Management, Rational Developer Network, Rational Rose, Rational XDE, Purify, PureCoverage, Rational Unified Process, ClearDDTS, and Quantify are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries or both. Microsoft Visual Basic, Windows NT, Windows 2000, Windows 95/98, Windows XP, Microsoft Word, Windows Explorer, DOS, PowerPoint, and Visual SourceSafe, among others, are trademarks or registered trademarks of Microsoft Corporation. Java and all Java-based marks, among others, are trademarks or registered trademarks of Sun Microsystems in the United States, other countries or both. UNIX is a registered trademark of The Open Group in the United States, other countries or both. Other company, product and service names may be trademarks or service marks of others. Printed in the United States of America. Contents Module 7 Identify Design Elements Identify Design Elements Overview Identifying Design Classes Identifying Interfaces Identify Reuse Opportunities Layering Considerations Review Module 8 Identify Design Mechanisms Identify Design Mechanisms Overview What Is a Design Pattern? Describing Analysis Mechanisms What Is a Combined Fragment? Review Module 9 Describe the Run-Time Architecture Describe the Run-time Architecture Overview What Is Concurrency? Identifying Processes and Threads Creating and Destroying Processes and Threads Mapping Processes onto the Implementation Design Elements-to-Processes Strategies Review Module 10 Describe Distribution Describe Distribution Overview The Network Configuration Process-to-Node Allocation Considerations What is Deployment? Distribution Mechanism Review This manual prepared by: IBM Rational Software Homestead Road Cupertino, CA USA

3 Module 7 Identify Design Elements IBM Software Group Mastering Object-Oriented Analysis and Design with UML 2.0 Module 7: Identify Design Elements 1 Topics Identify Design Elements Overview Identifying Design Classes Identifying Interfaces Identify Reuse Opportunities Layering Considerations Review Copyright IBM Corp

4 Module 7 - Identify Design Elements Objectives: Identify Design Elements Objectives: Identify Design Elements Identify Design Elements in Context Identify Design Elements in Context Define the purpose of Identify Design Elements and demonstrate where in the lifecycle it is performed Analyze interactions of analysis classes and identify Design Model elements Design classes Subsystems Subsystem interfaces Identify Design Elements Architect [Early Elaboration Iteration] Define a Candidate Architecture Refine the Architecture Design Components [Inception Iteration (Optional)] Perform Architectural Synthesis Analyze Behavior Design the Database (Optional) 2 3 In this module, we will describe WHAT is performed in Identify Design Elements, but will not describe HOW to do it. Such a discussion is the purpose of an architecture course, which this course is not. Understanding the rationale and considerations that support the architectural decisions is needed in order to understand the architecture, which is the framework in which designs must be developed. As you may recall, the above diagram illustrates the workflow that we are using in this course. It is a tailored version of the Analysis and Design core workflow of the Rational Unified Process. Identify Design Elements is an activity in the Refine the Architecture workflow detail. In Architectural Analysis, an initial attempt was made to define the layers of our system, concentrating on the upper layers. In Use-Case Analysis, you analyzed your requirements and allocated the responsibilities to analysis classes. In Identify Design Elements, the analysis classes are refined into design elements (design classes and subsystems). In Use-Case Analysis, you were concerned with the what. In the architecture activities, you are concerned with the how (for example, Design). Architecture is about making choices. 7-2 Copyright IBM Corp Copyright IBM Corp

5 Module 7 - Identify Design Elements Identify Design Elements Overview Identify Design Elements Overview Supplementary Specifications Software Architecture Document Project Specific Guidelines Identify Design Elements Steps Identify Design Elements Steps Identify classes and subsystems Identify subsystem interfaces Update the organization of the Design Model Checkpoints Identify Design Elements Design Model Analysis Model 5 The architect performs Identify Design Elements, once per iteration. Purpose To analyze interactions of analysis classes to identify Design Model elements Input Artifacts Supplementary Specifications Project Specific Guidelines Software Architecture Document Analysis Classes Analysis Model Design Model Resulting Artifacts Design Model elements Classes Packages Subsystems 4 The above are the topics we will be discussing within the Identify Design Elements module. Unlike the designer activity modules, we will not be discussing each step of the activity, as the objective of this module is to understand the important Identify Design Elements concepts, not to learn HOW to create an architecture. 7-4 Copyright IBM Corp Copyright IBM Corp

6 Module 7 - Identify Design Elements Identify Design Elements Steps Identify Design Elements Steps Identify classes and subsystems Identify subsystem interfaces Identify reuse opportunities Update the organization of the Design Model Checkpoints From Analysis Classes to Design Elements From Analysis Classes to Design Elements Analysis Classes <<boundary>> <<entity>> <<control>> Design Elements <<subsystem>> Subsystem Analysis Classes <<boundary>> <<subsystem>> Subsystem Many-to-Many Mapping 6 7 The purpose of Identify Classes and Subsystems is to refine the analysis classes into appropriate Design Model elements. Remember, analysis classes will seldom retain their same structure through Design. Analysis classes may be expanded, collapsed, combined, or even deleted in Design. Identify Design Elements is where the analysis classes identified during Use-Case Analysis are refined into design elements (for example, classes or subsystems). Analysis classes handle primarily functional requirements, and model objects from the "problem" domain; design elements handle nonfunctional requirements, and model objects from the "solution" domain. It is in Identify Design Elements that you decide which analysis classes are really classes, which are subsystems (which must be further decomposed), and which are existing components and do not need to be designed at all. Once the design classes and subsystems have been created, each must be given a name and a short description. The responsibilities of the original analysis classes should be transferred to the newly created subsystems. In addition, the identified design mechanisms should be linked to design elements. 7-6 Copyright IBM Corp Copyright IBM Corp

7 Module 7 - Identify Design Elements Identifying Design Classes Identifying Design Classes An analysis class maps directly to a design class if: It is a simple class It represents a single logical abstraction More complex analysis classes may Split into multiple classes Become a package Become a subsystem (discussed later) Any combination Review: Class and Package Review: Class and Package What is a class? A description of a set of objects that share the same responsibilities, relationships, operations, attributes, and semantics Class Name What is a package? A general purpose mechanism for organizing elements into groups A model element which can contain other model elements Package Name 9 If the analysis class is simple and already represents a single logical abstraction, then it can be directly mapped, one-to-one, to a design class. Typically, entity classes survive relatively intact into Design. Throughout the design activities, analysis classes are refined into design elements (for example, design classes, packages, and subsystems). Some analysis classes may be split, joined, removed, or otherwise manipulated. In general, there is a many-tomany mapping between analysis classes and design elements. The possible mappings include the following. An analysis class can become: One single class in the Design Model. A part of a class in the Design Model. An aggregate class in the Design Model (meaning that the parts in this aggregate may not be explicitly modeled in the Analysis Model.) A group of classes that inherits from the same class in the Design Model. A group of functionally related classes in the Design Model (for example, a package). A subsystem in the Design Model. A relationship in the Design Model. A relationship between analysis classes can become a class in the Design Model. Part of an analysis class can be realized by hardware, and not modeled in the Design Model at all. Any combination of the above. 8 A package is a general purpose mechanism for organizing elements into groups. They provide the ability to organize the model under development. A package is represented as a tabbed folder. Later in this module, we will contrast vanilla packages, as defined above, with subsystems. 7-8 Copyright IBM Corp Copyright IBM Corp

8 Module 7 - Identify Design Elements Group Design Classes in Packages Group Design Classes in Packages Packaging Tips: Boundary Classes Packaging Tips: Boundary Classes You can base your packaging criteria on a number of different factors, including: Configuration units Allocation of resources among development teams Reflect the user types Package C Represent the existing products and services the system uses Package B Package A If it is likely the system interface will undergo considerable changes Boundary classes placed in separate packages If it is unlikely the system interface will undergo considerable changes Boundary classes packaged with functionally related classes When identifying classes, you should group them into packages, for organizational and configuration management purposes. The Design Model can be structured into smaller units to make it easier to understand. By grouping Design Model elements into packages and subsystems, then showing how those groupings relate to one another, it is easier to understand the overall structure of the model. You might want to partition the Design Model for a number of reasons: You can use packages and subsystems as order, configuration, or delivery units when a system is finished. Allocation of resources and the competence of different development teams might require that the project be divided among different groups at different sites. Subsystems can be used to structure the Design Model in a way that reflects the user types. Many change requirements originate from users; subsystems ensure that changes from a particular user type will affect only the parts of the system that correspond to that user type. Subsystems are used to represent the existing products and services that the system uses. When the boundary classes are distributed to packages, there are two different strategies that can be applied. Which one to choose depends on whether or not the system interfaces are likely to change greatly in the future. If it is likely that the system interface will be replaced, or undergo considerable changes, the interface should be separated from the rest of the Design Model. When the user interface is changed, only these packages are affected. An example of such a major change is the switch from a line-oriented interface to a window-oriented interface. If no major interface changes are planned, changes to the system services should be the guiding principle, rather than changes to the interface. The boundary classes should then be placed together with the entity and control classes with which they are functionally related. This way, it will be easy to see what boundary classes are affected if a certain entity or control class is changed. Mandatory boundary classes that are not functionally related to any entity or control classes, should be placed in separate packages, together with boundary classes that belong to the same interface. If a boundary class is related to an optional service, group it in a separate subsystem with the classes that collaborate to provide the service. The subsystem will map onto an optional component that will be provided when the optional functionality is ordered Copyright IBM Corp Copyright IBM Corp

9 Module 7 - Identify Design Elements Packaging Tips: Functionally Related Classes Packaging Tips: Functionally Related Classes Criteria for determining if classes are functionally related: Changes in one class' behavior and/or structure necessitate changes in another class Removal of one class impacts the other class Two objects interact with a large number of messages or have a complex intercommunication A boundary class can be functionally related to a particular entity class if the function of the boundary class is to present the entity class Two classes interact with, or are affected by changes in the same actor Packaging Tips: Functionally Related Classes (continued) Packaging Tips: Functionally Related Classes (continued) Criteria for determining if classes are functionally related (continued): Two classes have relationships between each other One class creates instances of another class Criteria for determining when two classes should NOT be placed in the same package: Two classes that are related to different actors should not be placed in the same package An optional and a mandatory class should not be placed in the same package A package should be identified for each group of classes that are functionally related. There are several practical criteria that can be applied when judging if two classes are functionally related. These are, in order of diminishing importance: If changes in one class' behavior and/or structure necessitate changes in another class, the two classes are functionally related. It is possible to find out if one class is functionally related to another by beginning with a class for example, an entity class and examining the impact of it being removed from the system. Any classes that become superfluous as a result of a class removal are somehow connected to the removed class. By superfluous, we mean that the class is only used by the removed class, or is itself dependent upon the removed class. Two objects can be functionally related if they interact with a large number of messages, or have an otherwise complicated intercommunication. A boundary class can be functionally related to a particular entity class if the function of the boundary class is to present the entity class. Two classes can be functionally related if they interact with, or are affected by changes in, the same actor. If two classes do not involve the same actor, they should not lie in the same package. The last rule can, of course, be ignored for more important reasons. Two classes can be functionally related if they have relationships between each other (associations, aggregations, and so on). Of course, this criterion cannot be followed mindlessly but can be used when no other criterion is applicable. A class can be functionally related to the class that creates instances of it. These two criteria determine when two classes should not be placed in the same package: Two classes that are related to different actors should not be placed in the same package. An optional and a mandatory class should not be placed in the same package Copyright IBM Corp Copyright IBM Corp

10 Module 7 - Identify Design Elements Package Dependencies: Package Element Visibility Package Dependencies: Package Element Visibility A B Public visibility Private visibility PackageA + Class A1 PackageB + Class B1 + Class A3 + Class A2 - Class B2 OO Principle: Encapsulation Only public classes can be referenced outside of the owning package Package Coupling: Tips Package Coupling: Tips Packages should not be cross-coupled Packages in lower layers should not be dependent upon packages in upper layers In general, dependencies should not skip layers Upper Layer Lower Layer A X A X B X = Coupling violation C B X In Architectural Analysis, we discussed package dependencies. Now let s look at package dependencies in more detail and see how visibility can be defined. Visibility can be defined for package elements the same way it is defined for class attributes and operations. This visibility allows you to specify how other packages can access the elements that are owned by the package. The visibility of a package element can be expressed by including a visibility symbol as a prefix to the package element name. There are three types of visibility defined in the UML: Public: Public classes can be accessed outside of the owning package. Visibility symbol: +. Protected: Protected classes can only be accessed by the owning package and any packages that inherit from the owning package. Visibility symbol: #. Private: Private classes can only be accessed by classes within the owning package. Visibility symbol: -. The public elements of a package constitute the package s interface. All dependencies on a package should be dependencies on public elements of the package. Package visibility provides support for the OO principle of encapsulation. Package coupling is good and bad: Good, because coupling represents re-use, and bad, because coupling represents dependencies that make the system harder to change and evolve. Some general principles can be followed: Packages should not be cross-coupled (that is, co-dependent); for example, two packages should not be dependent on one another. In these cases, the packages need to be reorganized to remove the cross-dependencies. Packages in lower layers should not be dependent upon packages in upper layers. Packages should only be dependent upon packages in the same layer and in the next lower layer. In these cases, the functionality needs to be repartitioned. One solution is to state the dependencies in terms of interfaces, and organize the interfaces in the lower layer. In general, dependencies should not skip layers, unless the dependent behavior is common across all layers, and the alternative is to simply pass through operation invocations across layers. Packages should not depend on subsystems only on other packages or on interfaces Copyright IBM Corp Copyright IBM Corp

11 Module 7 - Identify Design Elements Example: Registration Package Example: Registration Package Example: University Artifacts Package: Generalization Example: University Artifacts Package: Generalization MainStudentForm MainRegistrarForm 0..1 <<boundary>> RegisterForCoursesForm <<boundary>> CloseRegistrationForm <<entity>> Student <<entity>> ScheduleOfferingInfo 1 <<entity>> FulltimeStudent <<entity>> ParttimeStudent <<entity>> PrimaryScheduleOfferingInfo 1 <<control>> RegistrationController 1 <<control>> CloseRegistrationController The next few slides describe the packaging decisions for the Course Registration System. All classes specifically supporting registration were partitioned into the Registration package. For simplicity on the above diagram, only the Student Registration package classes have been shown, and the operations and attributes are not displayed Copyright IBM Corp Copyright IBM Corp

12 Module 7 - Identify Design Elements Example: University Artifacts Package: Associations Example: University Artifacts Package: Associations Example: External System Interfaces Package Example: External System Interfaces Package <<entity>> Student 1 0..* 0..* <<entity>> Schedule 0..* <<Interface>> IBillingSystem <<Interface>> ICourseCatalogSystem primarycourses 0..4 <<entity>> instructor Professor * <<entity>> CourseOffering 0..* 1 CourseOfferingList alternatecourses 0..2 <<entity>> 0..* Course 0..* 0..* 1 Prerequisites The external system access classes were partitioned into the External System Interfaces package. This is so that the external system interface classes can be configuration-managed independently from the subsystems that realize them. For simplicity, only the External System Interfaces package classes have been shown on the above diagram. The operations and attributes are not displayed Copyright IBM Corp Copyright IBM Corp

13 Module 7 - Identify Design Elements Review: Subsystems and Interfaces Review: Subsystems and Interfaces Realizes one or more interfaces that define its behavior Interface <<interface>> Interface Name <<subsystem>> Subsystem Name Realization (Canonical form) Subsystem Subsystems and Interfaces (continued) Subsystems and Interfaces (continued) Subsystems : Completely encapsulate behavior Represent an independent capability with clear interfaces (potential for reuse) Model multiple implementation variants <<subsystem>> SubsystemA ClassA1 ClassA2 Interface Name Realization (Elided form) <<subsystem>> Subsystem Name <<Interface>> InterfaceK X() W() W() ClassB1 W() Y() X() <<subsystem>> SubsystemB ClassB2 X() ClassB3 Z() A subsystem is a model element that has the semantics of a package, such that it can contain other model elements, and a class, such that it has behavior. A subsystem realizes one or more interfaces, which define the behavior it can perform. A subsystem can be represented as a UML package (that is, a tabbed folder) with the «subsystem» stereotype. An interface is a model element that defines a set of behaviors (a set of operations) offered by a classifier model element (specifically, a class, subsystem, or component). The relationship between interfaces and classifiers (subsystems) is not always one-toone. An interface can be realized by multiple classifiers, and a classifier can realize multiple interfaces. Realization is a semantic relationship between two classifiers. One classifier serves as the contract that the other classifier agrees to carry out. The realization relationship can be modeled as a dashed line with a hollow arrowhead pointing at the contract classifier (canonical form), or when combined with an interface, as a ball (elided form). Thus, in the above example, the two interface/subsystem pairs with the relation between them are synonymous. Interfaces are a natural evolution from the public classes of a package (described on the previous slide) to abstractions outside the subsystem. Interfaces are pulled out of the subsystem like a kind of antenna, through which the subsystem can receive signals. All classes inside the subsystem are then private and not accessible from the outside. A subsystem encapsulates its implementation behind one (or more) interfaces. Interfaces isolate the rest of the architecture from the details of the implementation. Operations defined for the interface are implemented by one or more elements contained within the subsystem. An interface is a pure specification. Interfaces provide the family of behavior that a classifier that implements the interface must support. Interfaces are separate things that have separate life spans from the elements that realize them.this separation of interface and implementation exemplifies the OO concepts of modularity and encapsulation, as well as polymorphism. Note: Interfaces are not abstract classes. Abstract classes allow you to provide default behavior for some or all of their methods. Interfaces provide no default behavior. As mentioned earlier, an interface can be realized by one or more subsystems. Any two subsystems that realize the same interfaces can be substituted for one another. The benefit of this is that, unlike a package, the contents and internal behaviors of a subsystem can change with complete freedom, so long as the subsystem's interfaces remain constant. In the above example, InterfaceK defines the operations X() and Y(). Both SubsystemA and SubsystemB realize InterfaceK, which means that they provide the implementation for operations X() and Y(). Thus, SubsystemA and SubsystemB are completely plug-and-playable (that is, one can be replaced by the other without any impacts on clients of the subsystems) Copyright IBM Corp Copyright IBM Corp

14 Module 7 - Identify Design Elements Packages versus Subsystems Packages versus Subsystems Subsystems Provide behavior Completely encapsulate their contents Are easily replaced <<subsystem>> Subsystem A Client Class ClassB1 Encapsulation is the key! 22 Packages Don t provide behavior Don t completely encapsulate their contents May not be easily replaced Package B ClassB2 Subsystem Usage Subsystem Usage Subsystems can be used to partition the system into parts that can be independently: ordered, configured, or delivered developed, as long as the interfaces remain unchanged deployed across a set of distributed computational nodes changed without breaking other parts of the systems Subsystems can also be used to: partition the system into units which can provide restricted security over key resources represent existing products or external systems in the design (e.g. components) Subsystems raise the level of abstraction. 23 Subsystems and packages are very alike, but are different in some essential ways. A subsystem provides interfaces by which the behavior it contains can be accessed. Packages provide no behavior; they are simply containers of things that have behavior. Packages help organize and control sets of classes that are needed in common, but which are not really subsystems. Packages are just used for model organization and configuration management. Subsystems completely encapsulate their contents, providing behavior only through their interfaces. Dependencies on a subsystem are on its interface(s), not on specific subsystem contents. With packages, dependencies are on specific elements within the package. Subsystems provide a replaceable design element: Any two subsystems (or classes, for that matter) that realize the same interfaces are interchangeable. Subsystems support multiple implementation variants. Subsystems can be used when modeling one of many implementation variants. Subsystems can be used to represent components from the Implementation Model in the Design Model. With subsystems, the contents and internal behaviors of a subsystem can change with complete freedom as long as the subsystem's interfaces remain constant. With packages, it is impossible to substitute packages for one another unless they have the same public classes. The public classes and their public operations get frozen by the dependencies that external classes have on them. Thus, the designer is not free to eliminate these classes or change their behaviors if a better idea presents itself. Note: Even when using packages, it is important that you hide the implementation from elements external to the package. All dependencies on a package should be on the public classes of the package. Public classes can be considered the interface of the package and should be managed as such (stabilized early) Copyright IBM Corp Copyright IBM Corp

15 Module 7 - Identify Design Elements Identifying Subsystems Hints Identifying Subsystems Hints Look at object collaborations. Look for optionality. Look to the user interface of the system. Look to the actors. Look for coupling and cohesion between classes. Look at substitution. Look at distribution. Look at volatility. Candidate Subsystems Candidate Subsystems Analysis classes which may evolve into subsystems: Classes providing complex services and/or utilities Boundary classes (user interfaces and external system interfaces) Existing products or external systems in the design (e.g., components): Communication software Database access support Types and data structures Common utilities Application-specific products <<subsystem>> Subsystem A <<subsystem>> Subsystem C <<subsystem>> Subsystem B Object collaborations: If the classes in a collaboration interact only with each other to produce a well-defined set of results, then encapsulate them within a subsystem. Optionality: If collaborations model optional behavior, or features that may be removed, upgraded, or replaced with alternatives, then encapsulate them within a subsystem. User interface: Create horizontal subsystems (boundary classes and related entity classes in separate subsystems) or vertical subsystems (related boundary and entity classes in the same subsystem), depending on the coupling of the user interface and entity classes. Actors: Partition functionality used by two different actors, since each actor can independently change requirements. Class coupling and cohesion: Organize highly coupled classes into subsystems, separating along the lines of weak coupling. Substitution: Represent different service levels for a particular capability (for example, high, medium, and low availability) as a separate subsystem, that realizes the same interfaces. Distribution: If particular functionality must reside on a particular node, ensure that the subsystem functionality maps onto a single node. Volatility: You will want to encapsulate those chunks of your system that you expect to change. Examples of analysis classes that may evolve into subsystems include: Classes providing complex services and/or utilities. For example: Credit or risk evaluation engines in financial applications Rule-based evaluation engines in commercial applications Security authorization services in most applications. Boundary classes, both for user interfaces and external system interfaces. If the interface(s) are simple and well-defined, a single class may be sufficient. Often, however, these interfaces are too complex to be represented using a single class. They often require complex collaborations of many classes. Moreover, these interfaces may be reusable across applications. As a result, a subsystem more appropriately models these interfaces in many cases. Examples of products the system uses that you can represent by a subsystem include: Communication software (middle-ware, COM/CORBA support) Database access support (RDBMS mapping support) Types and data structures (stacks, lists, queues) Common utilities (math libraries) Application-specific products (billing system, scheduler) Interfaces and subsystems provide the necessary decoupling between interface and implementation to model (in Design) what components do for Implementation Copyright IBM Corp Copyright IBM Corp

16 Module 7 - Identify Design Elements Identifying Subsystems Identifying Subsystems Identify Design Elements Steps Identify Design Elements Steps Superman Class <<Interface>> InterfaceK <<control>> ClassA X() W() <<subsystem>> SubsystemA Identify classes and subsystems Identify subsystem interfaces Identify reuse opportunities Update the organization of the Design Model Checkpoints X() W() ClassA1 X() ClassA2 W() When the analysis class is complex, such that it appears to embody behaviors that cannot be the responsibility of a single class acting alone, or the responsibilities may need to be reused, the analysis class should be refined into a subsystem. This is a decision based largely on conjecture guided by experience. The actual representation may take a few iterations to stabilize. As discussed earlier, the use of a subsystem allows the interface to be defined and stabilized, while leaving the design details of the interface implementation to remain hidden while its definition evolves. The decision to make something a subsystem is often driven by the knowledge and experience of the architect. Since it tends to have a strong effect on the partitioning of the solution space, the decision needs to be made in the context of the whole model. It is the result of more detailed design knowledge, as well as the imposition of constraints imposed by the implementation environment. When an analysis class is evolved into a subsystem, the responsibilities that were allocated to the superman analysis class are then allocated to the subsystem and an associated interface (that is, they are used to define the interface operations). The details of how that subsystem actually implements the responsibilities (that is, the interface operations) is deferred until Subsystem Design. Interfaces define a set of operations that are realized by some classifier. In the Design Model, interfaces are principally used to define the interfaces for subsystems. This is not to say that they cannot be used for classes as well. But for a single class it is usually sufficient to define public operations on the class. These operators, in effect, define its interface. Interfaces are important for subsystems because they allow the separation of the declaration of behavior (the interface) from the realization of behavior (the specific classes within the subsystem that realize the interface). This de-coupling provides us with a way to increase the independence of development teams working on different parts of the system, while retaining precise definitions of the contracts between these different parts Copyright IBM Corp Copyright IBM Corp

17 Module 7 - Identify Design Elements Identifying Interfaces Identifying Interfaces Purpose To identify the interfaces of the subsystems based on their responsibilities Steps Identify a set of candidate interfaces for all subsystems. Look for similarities between interfaces. Define interface dependencies. Map the interfaces to subsystems. Define the behavior specified by the interfaces. Package the interfaces. Stable, well-defined interfaces are key to a stable, resilient architecture. Once the subsystems are identified, their interfaces need to be identified. Identify candidate interfaces. Organize the subsystem responsibilities into groups of cohesive, related responsibilities. These groupings define the initial, first-cut set of interfaces for the subsystem. To start with, identify an operation for each responsibility, complete with parameters and return values. Look for similarities between interfaces. Look for similar names, similar responsibilities, and similar operations. Extract common operations into a new interface. Be sure to look at existing interfaces as well, re-using them where possible. Define interface dependencies. Add dependency relationships from the interface to all classes and/or interfaces that appear in the interface operation signatures. Map the interfaces to subsystems. Create realization associations from the subsystem to the interface(s) it realizes. Define the behavior specified by the interfaces. If the operations on the interface must be invoked in a particular order, define a state machine that illustrates the publicly visible (or inferred) states that any design element that realizes the interface must support. Package the interfaces. Interfaces can be managed and controlled independently of the subsystems themselves. Partition the interfaces according to their responsibilities. 28 Interface Guidelines Interface Guidelines Interface name Reflects role in system Interface description Conveys responsibilities Operation definition Name should reflect operation result Describes what operation does, all parameters and result Interface documentation Package supporting info: sequence and state diagrams, test plans, etc. 29 Interface name: Name the interface to reflect the role it plays in the system. The name should be short one-to-two words. It is not necessary to include the word "interface" in the name; it is implied by the type of model element (that is, interface). Interface description: The description should convey the responsibilities of the interface.the description should be several sentences long, up to a short paragraph. The description should not simply restate the name of the interface. Instead, it should illuminate the role the interface plays in the system. Operation definition: Each interface should provide a unique and well-defined set of operations. Operation names should reflect the result of the operation. When an operation sets or gets information, including set or get in the name of the operation is redundant. Give the operation the same name as the property of the model element that is being set or retrieved. Example: name() returns the name of the object; name(astring) sets the name of the object to astring. The description of the operation should describe what the operation does, including any key algorithms, and what value it returns. Name the parameters of the operation to indicate what information is being passed to the operation. Identify the type of the parameter. Interface documentation: The behavior defined by the interface is specified as a set of operations Copyright IBM Corp Copyright IBM Corp

18 Module 7 - Identify Design Elements Example: Design Subsystems and Interfaces Example: Design Subsystems and Interfaces Analysis <<boundary>> BillingSystem //submit bill() <<boundary>> CourseCatalogSystem //get course offerings() Design <<subsystem>> Billing System IBillingSystem submitbill(fortuition : Double, forstudent : Student) <<subsystem>> Course Catalog System Example: Analysis-Class-To-Design-Element Map Example: Analysis-Class-To-Design-Element Map Analysis Class CourseCatalogSystem BillingSystem All other analysis classes map directly to design classes Design Element CourseCatalogSystem Subsystem BillingSystem Subsystem ICourseCatalogSystem getcourseofferings(forsemester : Semester, forstudent : Student) : CourseOfferingList initialize() All other analysis classes map directly to design classes During Use-Case Analysis, we modeled two boundary classes, the BillingSystem and the CourseCatalogSystem, whose responsibilities were to cover the details of the interfaces to the external systems. It was decided by the architects of the Course Registration System that the interactions to support external system access will be more complex than can be implemented in a single class. Thus, subsystems were identified to encapsulate these responsibilities and provide interfaces that give the external systems access. The above diagram includes these subsystems, as well as their interfaces. The BillingSystem subsystem provides an interface to the external billing system. It is used to submit a bill when registration ends and students have been registered in courses. The CourseCatalogSystem subsystem encapsulates all the work involved for communicating to the legacy Course Catalog System. The system provides access to the unabridged catalog of all courses and course offerings provided by the university, including those from previous semesters. These are subsystems rather than packages because a simple interface to their complex internal behaviors can be created. Also, by using a subsystem with an explicit and stable interface, the particulars of the external systems to be used (in this case, the Billing System and the legacy Course Catalog System) could be changed at a later date with no impact on the rest of the system. The above table is an example of how you could document the mapping of analysis classes to design elements. This may be refined as the Design process continues Copyright IBM Corp Copyright IBM Corp

19 Module 7 - Identify Design Elements Modeling Convention: Subsystems and Interfaces Modeling Convention: Subsystems and Interfaces Example: Subsystem Context: CourseCatalogSystem Example: Subsystem Context: CourseCatalogSystem <<subsystem>> CourseCatalogSystem ICourseCatalogSystem + initialize () + getcourseofferings () <<control>> CloseRegistrationController + // is registration open?() + // close registration() coursecatalog 1 <<Interface>> ICourseCatalogSystem Required interface defined <<control>> RegistrationController + getcurrentschedule() + deletecurrentschedule() + submitschedule() + saveschedule() + getcourseofferings() + setsession() + <<class>> new() + getstudent() Interfaces start with an I + getcourseofferings ( for Semester: Semester ) + initialize () <<interface>> ICourseCatalogSystem + getcourseofferings () + initialize () <<subsystem>> CourseCatalogSystem + initialize () + getcourseofferings () Provided interface defined <<subsystem>> CourseCatalogSystem CourseOfferingList + new() + add() + initialize () + getcourseofferings () For this course, we will represent subsystems as three items in the model: A <<subsystem>> package (that is, package with a stereotype of <<subsystem>>), A <<subsystem proxy>> class (that is, class with a stereotype of <<subsystem proxy>>) A subsystem interface (class with a stereotype of <<interface>>. The interface names will start with an I. The <<subsystem>> package provides a container for the elements that comprise the subsystem, the interaction diagrams that describe how the subsystem elements collaborate to implement the operations of the interfaces the subsystem realizes, and other diagrams that clarify the subsystem elements. The subsystem realizes the interface. The <<subsystem proxy>> class realizes the interface(s) (as a proxy) and will orchestrate the implementation of the subsystem interface(s) operations. (This will be discussed further in the module on Subsystem Design.) Such conventions make the consistent modeling of subsystems easier. We will see later in the course how we utilize this convention in representing subsystems in our diagrams. Remember, interfaces are EXTERNAL to the subsystem package. The above is a context diagram for the CourseCatalogSystem subsystem. A subsystem context class diagram should contain the subsystem, interface(s), associated realizes relationship(s), and any subsystem relationships (both to/from the subsystem and from/to other design elements). The ICourseCatalogSystem interface is dependent on the CourseOfferingList class as the CourseOfferingList class appears in the signature of one its operations. The RegistrationController and the CloseRegistrationController classes are dependent on the ICourseCatalogSystem interface to obtain the list of CourseOfferings being offered for a particular semester. Notice the use of the modeling conventions, especially the subsystem proxy class and the realization relationship. In Identify Design Elements, the interfaces are completely defined, including their signatures. This is important, as these interfaces will serve as synchronization points that enable parallel development. There is not a Semester class. It is envisioned that this will be some type of enumeration in the implementation Copyright IBM Corp Copyright IBM Corp

20 Module 7 - Identify Design Elements Example: Subsystem Context: Billing System Example: Subsystem Context: Billing System Identify Design Elements Steps Identify Design Elements Steps <<control>> CloseRegistrationController + // is registration open?() + // close registration() Biller 1 <<Interface>> 1 IBillingSystem + submitbill(forstudent : Student, fortuition : double) <<entity>> Student Identify classes and subsystems Identify subsystem interfaces Identify reuse opportunities Update the organization of the Design Model Checkpoints <<subsystem>> BillingSystem + submitbill(forstudent : Student, fortuition : double) The above is a context diagram for the BillingSystem subsystem. A subsystem context class diagram should contain the subsystem, interface(s), associated realizes relationship(s), and any subsystem relationships (both to/from the subsystem and from/to other design elements). The IBillingSystem interface is dependent on the student class as the student class appears in the signature of one its operations. (Stay tuned for dependencies in the Class Design module.) The CloseRegistrationController is dependent on the IBillingSystem interface to bill the student for the courses he or she is enrolled in. Notice the use of the modeling conventions, especially the subsystem proxy class and the realization relationship. The identification of reuse opportunities is an important architectural step. It will help you to determine which subsystems and packages to develop, which ones to reuse, and which ones to buy. It is desirable to reuse existing components, wherever possible. Such reuse allows you to leverage existing successful implementations, eliminating (or greatly reducing) the resources needed to develop and test the component. The identification of reuse opportunities is a unification effort, since it is determined if things that have been identified can be satisfied by what already exists. The most effective reuse identification occurs after there is an understanding of the required behavior of the system and after some initial partitioning of the design elements has occurred. On the next three slides, you will see the possible sources of reuse and how such reuse could be incorporated into the architecture Copyright IBM Corp Copyright IBM Corp

21 Module 7 - Identify Design Elements Identify Reuse Opportunities Identification of Reuse Opportunities Purpose To identify where existing subsystems and/or components can be reused based on their interfaces. Steps Look for similar interfaces Modify new interfaces to improve the fit Replace candidate interfaces with existing interfaces Map the candidate subsystem to existing components Possible Reuse Opportunities Possible Reuse Opportunities Internal to the system being developed Recognized commonality across packages and subsystems External to the system being developed Commercially available components Components from a previously developed application Reverse engineered components 37 Software Software 36 Look for existing subsystems or components that offer similar interfaces. Compare each identified interface to the interfaces provided by existing subsystems or components. There usually will not be an exact match, but approximate matches can be found. Look first for similar behavior and returned values, then consider parameters. Modify the newly identified interfaces to improve the fit. There may be opportunities to make minor changes to a candidate interface that will improve its conformance to the existing interface. Simple changes include rearranging or adding parameters to the candidate interface. They also include factoring the interface by splitting it into several interfaces, one or more of which match those of the existing component, with the "new" behaviors located in a separate interface. Replace candidate interfaces with existing interfaces where exact matches occur. After simplification and factoring, if there is an exact match to an existing interface, eliminate the candidate interface and simply use the existing interface. Map the candidate subsystem to existing components. Look at existing components and the set of candidate subsystems. Factor the subsystems so that existing components are used wherever possible to satisfy the required behavior of the system. Where a candidate subsystem can be realized by an existing component, create traceability between the subsystem and the component. Note in the description for this subsystem that the behavior is satisfied by the associated existing component. In mapping subsystems onto components, consider the design mechanisms associated with the subsystem. Performance or security requirements may disqualify a component from reuse despite an otherwise perfect match between operation signatures. In organizations that build similar systems, there is often a set of common components that provide many of the architectural mechanisms needed for a new system. There may also be components available in the marketplace that also fill the need for architectural mechanisms. Existing components should be examined to determine their suitability and compatibility within the software architecture. These components can be reverse engineered into the Design Model for examination and incorporation. You can then use design elements as proxies for the components. This allows you to show how what has been bought and what needs to be built interact (a necessary requirement unless you are buying all your components and only doing assembly). The advent of commercially successful component infrastructures such as CORBA, the Internet, ActiveX and JavaBeans triggers a whole industry of off-the-shelf components for various domains, allowing you to buy and integrate components rather than developing them all in-house. Reusable components provide common solutions to a wide range of common problems and may be larger than just collections of utilities or class libraries; they form the basis of reuse within an organization, increasing overall software productivity and quality Copyright IBM Corp Copyright IBM Corp

22 Module 7 - Identify Design Elements Reuse Opportunities Internal to System Reuse Opportunities Internal to System? Identify Design Elements Steps Identify Design Elements Steps Identify classes and subsystems Identify subsystem interfaces Identify reuse opportunities Update the organization of the Design Model Checkpoints ClassB ClassC ClassD Y() Z() Y() Z() ClassA Y() Z() Y() Z() ClassC ClassE Y() Z() Y() Z() Reuse can be discovered within the current software system. There may be design elements that are needed by more than one subsystem or package. The above slide is meant to visually represent what happens as reuse is discovered: Build the first application and some general parts. Build the second application, and you find that some parts of the first can be reused, but the parts were not designed to be reused. (Some are reused any way, with chaos as result). It is recognized that something is being used by one element that other elements may find useful (first diagram). Take the candidate reusable design elements (classes, packages, or subsystems) and make them reusable. This may involve changing their names, making them more general, improving their documentation, moving them to a common functionality layer, etc. Essentially, the candidate reusable entity is pushed down to a lower layer in the architecture so other elements may access it. Initially, only the original client of the element may use it (second diagram). Now can you use them for the new application. When the first application is upgraded, the old versions of the elements can be replaced with the reusable ones (third diagram). It is important for the architect to look within and across the design elements for common behavior (for example, common collaborations), pulling it out where possible. This is a reuse scavenging activity that falls under the Identify Design Elements umbrella. Note: To see an example of reuse of a Security mechanism, refer to the Security Mechanism tab in the Additional Information Appendix. As new elements have been added to the Design Model, re-packaging the elements of the Design Model is often necessary. Repackaging achieves several objectives: It reduces coupling between packages and improves cohesion within packages in the Design Model. The ultimate goal is to allow different packages (and subsystems) to be designed and developed independently of one another by separate individuals or teams. While complete independence is probably impossible to achieve, loose coupling between packages tends to improve the ease of development of large or complex systems. As new model elements are added to the system, existing packages may grow too large to be managed by a single team: The package must be split into several packages which are highly cohesive within the package but loosely coupled between the packages. Doing this may be difficult some elements may be difficult to place in one specific package because they are used by elements of both packages. There are two possible solutions: Split the element into several objects, one in each package (this works where the element has several 'personalities,' or sets of somewhat disjoint responsibilities) Move the element into a package in a lower layer, where all higher layer elements might depend upon it equally. You will discuss modeling the lower layers in this step Copyright IBM Corp Copyright IBM Corp

23 Module 7 - Identify Design Elements Review: Typical Layering Approach Review: Typical Layering Approach Layering Considerations Layering Considerations Specific functionality General functionality Application Business-Specific Middleware System Software Distinct application subsystems that make up an application contains the value adding software developed by the organization. Business specific contains a number of reusable subsystems specific to the type of business. Middleware offers subsystems for utility classes and platform-independent services for distributed object computing in heterogeneous environments and so on. System software contains the software for the actual infrastructure such as operating systems, interfaces to specific hardware, device drivers, and so on. Visibility Dependencies only within current layer and below Volatility Upper layers affected by requirements changes Lower layers affected by environment changes Generality More abstract model elements in lower layers Number of layers Small system: 3-4 layers Complex system: 5-7 layers 40 Goal is to reduce coupling and to ease maintenance effort. This is a repeat of the slide first introduced in Architectural Analysis. It is included here as a review. During Architectural Analysis, the focus was on the upper-level layers (that is, the application and business-specific layers). During Identify Design Elements, the focus is on the lower-level layers. The layering principles originally described for packages also apply to subsystems. 41 Layering provides a logical partitioning of packages into layers with certain rules concerning the relationships between layers. Restricting inter-layer and inter-package dependencies makes the system more loosely coupled and easier to maintain. Failure to restrict dependencies causes architectural degradation, and makes the system brittle and difficult to maintain. Visibility: Elements should only depend on elements in the same layer and the next lower layer. Exceptions include cases where packages need direct access to lowerlayer services (for example, primitive services needed throughout the system, such as printing, sending messages, and so forth). There is little value in restricting messages to lower layers if the solution is to effectively implement call pass-throughs in the intermediate layers. Volatility: In the highest layers, put elements that vary when user requirements change. In the lowest layers, put elements that vary when the implementation platform (hardware, language, operating system, database, and so forth) changes. Sandwiched in the middle, put elements that are generally applicable across wide ranges of systems and implementation environments. Add layers when additional partitions within these broad categories help to organize the model. Generality: Abstract model elements tend to be placed lower in the model, where they can be reused. If not implementation-specific, they tend to gravitate toward the middle layers. Number of Layers: For a small system, three layers are sufficient. For a complex system, five-to-seven layers are usually sufficient. For any degree of complexity, more than ten layers should be viewed with suspicion that increases with the number of layers Copyright IBM Corp Copyright IBM Corp

24 Module 7 - Identify Design Elements Design Elements and the Architecture Design Elements and the Architecture Layer 1 Layer 2 Example: Architectural Layers Example: Architectural Layers <<layer>> Application <<layer>> Business Services Necessary because the Application Layer must have access to the core distribution mechanisms provided with Java RMI. <<layer>> Middleware Layer 3 Base Reuse global The identified design elements need to be allocated to specific layers in the architecture. The above diagram is not meant to recommend or suggest specific layers. What is meant is that layers are not just by stereotype. You can have boundary classes in the Business Services layer (for example, outgoing interfaces), control classes in the Middleware layer (for example, transaction manager), and so on. Even though all three stereotypes can appear in any layer, there are general trends that may help guide a novice designer. Most boundary classes tend to appear at the top, most control classes tend to appear in the services layer where control across entities is required, and most entities appear towards the bottom layers. An experienced designer makes packages of classes that work together to provide a service (that is, he or she groups pieces of the system together that work closely to support some high-level capability). This leads to cohesive, reusable packages. The layers defined in this activity are built on the architectural layers originally defined in Architectural Analysis. The Middleware layer and the Base Reuse package were added in this activity. The Middleware layer provides utilities and platform-independent services. The Base Reuse package contains some common, generic reusable design elements and patterns. The contents of each of these layers is described later in this module Copyright IBM Corp Copyright IBM Corp

25 Module 7 - Identify Design Elements Partitioning Considerations Partitioning Considerations Example: Partitioning Example: Partitioning Coupling and cohesion User organization Competency and/or skill areas System distribution Secrecy Variability A B Package A Package B Try to avoid cyclic dependencies Coupling and cohesion: Design elements with tight coupling/cohesion (for example, lots of relationships and communication) should be placed in the same partition. User organization: This occurs when an existing Enterprise Model has a strongly organizationally partitioned structure. Usually affects the top layers (applicationspecific services). Competence and/or skill areas: In the middle and lower layers, specialization in skills should be considered during the development and support of complex infrastructure technology (for example, network, distribution, database, and/or communication management; process control). In the upper layers, the specialization of skills should be considered in the problem domain (for example, telecommunication call management, securities trading, insurance claims processing, and air traffic control). System distribution: This helps to visualize the network communication, which will occur as the system executes. Secrecy areas: Functionality requiring special security clearance must be partitioned into subsystems that will be developed independently, with the interfaces to the secrecy areas the only visible aspect of these subsystems. Variability areas: Functionality that is likely to be optional, and thereby delivered only in some variants of the system, should be organized into subsystems. When partitioning, try to avoid circular dependencies, as they make it impossible to reuse one package without the other. The above example shows a partitioning of design elements. The diagram on the left shows some classes divided into two partitions, A and B. The diagram on the right shows the resulting packages. Notice the following: Maximum coupling and cohesion within packages versus minimal coupling between packages (left diagram). The dependencies between packages (right diagram) reflect/support the dependencies between the classes contained within the packages (left diagram) Copyright IBM Corp Copyright IBM Corp

26 Module 7 - Identify Design Elements Example: Application Layer Example: Application Layer Example: Application Layer Context Example: Application Layer Context <<layer>> Application <<layer>> Application <<layer>> Application <<layer>> Business Services Registration <<layer>> Business Services Registration External System Interfaces Security University Artifacts Secure Interfaces GUI Framework The next few slides describe the layering decisions for the Course Registration System. The Application layer contains application-specific design elements. The Registration package that was previously defined has been allocated to the Application layer. In the Course Registration example, we have been concentrating on the Student Registration application. As additional applications are defined within the Course Registration System, additional packages could be added to the Application layer for example, Student Evaluation. The Registration package depends on the University Artifacts package for the core abstractions, the External System Interface packages for the external system interfaces, and the GUI Framework and Security Interfaces packages for the security framework. Notice how the package dependencies are consistent with the layer dependencies Copyright IBM Corp Copyright IBM Corp

27 Module 7 - Identify Design Elements Example: Business Services Layer Example: Business Services Layer Example: Business Services Layer Context Example: Business Services Layer Context <<layer>> Business Services <<subsystem>> BillingSystem <<layer>> Business Services <<subsystem>> CourseCatalogSystem <<subsystem>> BillingSystem External System Interfaces <<subsystem>> CourseCatalogSystem ObjectStore Support External System Interfaces GUI Framework Security <<subsystem>> Security Manager <<layer>> Business Services ObjectStore Support GUI Framework Security <<subsystem>> Security Manager University Artifacts Secure Interfaces <<layer>> Middleware University Artifacts Secure Interfaces <<layer>> Middleware com.odi java.sql The Business Services layer contains business-specific elements that are used in several applications. The external system access subsystems, their interfaces, the key abstractions package, the OODBMS persistency support package, and the security package were placed in the Business Services layer. It is anticipated that these packages might be required by multiple applications. The above diagram models the context of the Business Services layer. It models the relationships that the Business Services layer has with the other layers in our architecture, and shows how the design element dependencies are consistent with the layer dependencies. Packages within the Business Services layer require access to the com.odi and java.sql packages in order to utilize the core persistency mechanisms Copyright IBM Corp Copyright IBM Corp

28 Module 7 - Identify Design Elements Example: Middleware Layer Example: Middleware Layer Identify Design Elements Steps Identify Design Elements Steps Map (from com.odi) com.odi Transaction (from com.odi) Session (from com.odi) Database (from com.odi) <<layer>> Middleware DriverManager (from com.odi) Statement (from com.odi) java.sql Connection (from com.odi) ResultSet (from com.odi) Identify classes and subsystems Identify subsystem interfaces Identify reuse opportunities Update the organization of the Design Model Checkpoints The Middleware layer provides utilities and platform-independent services. All of these packages are commercially available, com.odi from ObjectStore and java.sql with most standard Java IDEs. This is where the quality of the architecture modeled up to this point is assessed against some very specific criteria. In this module, we will concentrate on those checkpoints that the designer is most concerned with. The architect should do a much more detailed review of the Identify Design Elements results and correct any problems before the project moves on to the next activity. We will not cover those checkpoints, as they are out of scope of this course. (Remember, this is not an architecture course.) 7-50 Copyright IBM Corp Copyright IBM Corp

29 Module 7 - Identify Design Elements Checkpoints Checkpoints General Does it provide a comprehensive picture of the services of different packages? Can you find similar structural solutions that can be used more widely in the problem domain? Layers Are there more than seven layers? Subsystems Is subsystem partitioning done in a logically consistent way across the entire model? Checkpoints (continued) Checkpoints (continued) Packages Are the names of the packages descriptive? Does the package description match with the responsibilities of contained classes? Do the package dependencies correspond to the relationships between the contained classes? Do the classes contained in a package belong there according to the criteria for the package division? Are there classes or collaborations of classes within a package that can be separated into an independent package? Is the ratio between the number of packages and the number of classes appropriate? The next few slides contain the key things a designer would look for when assessing the results of Identify Design Elements. As stated earlier, an architect would have a more detailed list. A well-structured architecture: Encompasses a set of classes, typically organized into multiple hierarchies. Provides a set of collaborations that specify how those classes cooperate to provide various system functions. If the classes contained in a package do not belong there according to the criteria for the package division then move them to other packages or create more packages. If the classes in the packages are not related functionally, then move some of the classes to other packages or create more packages. As a guideline regarding an appropriate ratio between the number of packages and the number of classes, 5 packages and 1,000 classes is probably a sign that something is wrong Copyright IBM Corp Copyright IBM Corp

30 Module 7 - Identify Design Elements Checkpoints (continued) Checkpoints (continued) Classes Does the name of each class clearly reflect the role it plays? Is the class cohesive (i.e., are all parts functionally coupled)? Are all class elements needed by the use-case realizations? Do the role names of the aggregations and associations accurately describe the relationship? Are the multiplicities of the relationships correct? Review Review: Identify Design Elements What is the purpose of Identify Design Elements? What is an interface? What is a subsystem? How does it differ from a package? What is a subsystem used for, and how do you identify them? What are some layering and partitioning considerations? 54 A well-structured class: Provides a crisp abstraction of some thing drawn from the vocabulary of the problem domain or the solution domain. Embodies a small, well-defined set of responsibilities, and carries them all out very well. Provides a clear separation of the abstraction's behavior and its implementation. Is understandable and simple yet extensible and adaptable. A sampling of some class checkpoints are listed above. A more detailed set of checkpoints for classes will be discussed in the Class Design module Copyright IBM Corp Copyright IBM Corp

31 Module 7 - Identify Design Elements Exercise: Identify Design Elements Exercise: Identify Design Elements Given the following: The analysis classes and their relationships Payroll Exercise Solution, Use-Case Analysis, Part 2 (use-case realization VOPCs) The layers, packages, and their dependencies Exercise Workbook: Payroll Architectural Handbook, Logical View, Architectural Layers and their Dependencies Exercise: Identify Design Elements (continued) Exercise: Identify Design Elements (continued) Identify the following: Design classes, subsystems, their interfaces and their relationships with other design elements Mapping from the analysis classes to the design elements The location of the design elements (e.g. subsystems and their design classes) in the architecture (i.e., the package/layer that contains the design element) The goal of this exercise is to identify design elements (subsystems, interfaces, design classes) and then identify the location of the design elements in the architecture. Use the results of the Use-Case Analysis exercise as input for this activity. References to the givens: The analysis classes and their relationships: Payroll Exercise Solution, Use-Case Analysis, Part 2 (use-case realization VOPCs). The architectural layers and their dependencies: Exercise Workbook: Payroll Architectural Handbook, Logical View, Architectural Layers and their Dependencies. Review the previously defined analysis classes, and look for potential subsystems, keeping in mind the subsystem usage suggestions discussed in this module. For each subsystem you choose, be prepared to justify the choice. Remember to complete the signatures for the identified interfaces. Note: Subsystems might be depended on by other design elements. The dependencies on a subsystem should be on the subsystem interface(s). It is important to understand the context in which the subsystem exists. Once subsystems have been identified and their interfaces defined, it is important to document the mapping from the initial analysis classes to these design elements as this will provide analysis-to-design traceability. Up to this point, the analysis classes were not mapped to a specific position in the architecture. (They were not mapped to packages.) It is during Identify Design Elements that we must allocate the design elements (subsystems and classes) to an appropriate place in the architecture (that is, a package and/or layer). This involves partitioning, as we discussed earlier in the module. When partitioning the design elements, make sure that the dependencies between the packages and layers support the dependencies needed between the model elements contained in the packages and layers Copyright IBM Corp Copyright IBM Corp

32 Module 7 - Identify Design Elements Exercise: Identify Design Elements Exercise: Identify Design Elements Produce the following: For each subsystem, an interface realization class diagram Table mapping analysis classes to design elements Table listing design elements and their owning package Exercise: Review Exercise: Review Compare your results with the rest of the class What subsystem did you find? Is it partitioned logically? Does it realize an interface(s)? What analysis classes does it map to? Do the package dependencies correspond to the relationships between the contained classes? Are the classes grouped logically? Are there classes or collaborations of classes within a package that can be separated into an independent package? Payroll System The interface realization class diagram should contain the subsystem proxy class, the interface(s) the subsystem realizes, the associated realization relationship(s), and any subsystem relationships (both to and from the subsystem to other design elements). Since the objective of this exercise is NOT to do the design of the subsystems, in most cases this diagram will only contain relationships TO the subsystem INTERFACE. Be sure to use the conventions defined in the course. (For example, use the recommended stereotypes.) The produced table should have two columns: Design Element and Owning Package. The owning package is the UML package that directly contains the design element. Refer to the following slide if needed: Subsystem context diagrams: Slides After completing a model, it is important to step back and review your work. Some helpful questions are the following: Has the use case behavior been successfully represented in the model? In other words, is the flow of events the same in the specifications as it is in the model? Has there been any significant behavior that was added? Removed? Changed? The model should reflect the intent of the use-case specifications. Is each stereotype behaving properly? Are actors only interfacing with boundary classes? Are control classes controlling the use-case flow of events only? Are any classes doing operations on data (attributes) that are not owned by that class? 7-58 Copyright IBM Corp Copyright IBM Corp

33 Module 8 Identify Design Mechanisms IBM Software Group Mastering Object-Oriented Analysis and Design with UML 2.0 Module 8: Identify Design Mechanisms 1 Topics Identify Design Mechanisms Overview What Is a Design Pattern? Describing Analysis Mechanisms What Is a Combined Fragment? Review Copyright IBM Corp Copyright IBM Corp

34 Module 8 - Identify Design Mechanisms Objectives: Identify Design Mechanisms Objectives: Identify Design Mechanisms Identify Design Mechanisms in Context Identify Design Mechanisms in Context Define the purpose of the Identify Design Mechanisms activity and explain when in the lifecycle it is performed Explain what design and implementation mechanisms are and how they map from Analysis mechanisms Describe some key mechanisms that will be utilized in the case study Identify Design Mechanisms Architect [Early Elaboration Iteration] Define a Candidate Architecture Refine the Architecture [Inception Iteration (Optional)] Perform Architectural Synthesis Analyze Behavior (Optional) Design Components Design the Database 2 3 In this module, we will describe WHAT is performed in Identify Design Mechanisms, but will not describe how to do it. Such a discussion is the purpose of an architecture course, which this course is not. Understanding the rationale and considerations that support the architectural decisions is needed in order to understand the architecture, which is the framework in which designs must be developed. As you may recall, the above diagram illustrates the workflow that we are using in this course. It is a tailored version of the Analysis and Design core workflow of the Rational Unified Process. Identify Design Mechanisms is an activity in the Refine the Architecture workflow detail. Identify Design Mechanisms is where we refine the analysis mechanisms into design mechanisms based on the constraints imposed by the implementation environment. 8-2 Copyright IBM Corp Copyright IBM Corp

35 Module 8 - Identify Design Mechanisms Identify Design Mechanisms Overview Identify Design Mechanisms Overview Identify Design Mechanisms: Steps Identify Design Mechanisms: Steps Categorize clients of analysis mechanisms Document architectural mechanisms Supplementary Specifications Software Architecture Document Identify Design Mechanisms Design Model Analysis Class 5 Identify Design Mechanisms is performed by the architect, once per iteration. Purpose To refine the analysis mechanisms into design mechanisms based on the constraints imposed by the implementation environment. Input Artifacts Supplementary Specifications Software Architecture Document Analysis Class Design Model Resulting Artifacts Design Model elements Classes Packages Subsystems Software Architecture Document 4 The above are the topics we will be discussing within the Identify Design Elements module. Unlike the Designer activity modules, we will not be discussing each step of the activity, as the objective of this module is to understand the important architectural concepts and not to learn how to create an architecture. 8-4 Copyright IBM Corp Copyright IBM Corp

36 Module 8 - Identify Design Mechanisms Identify Design Mechanisms: Steps Identify Design Mechanisms: Steps Categorize clients of analysis mechanisms Documenting architectural mechanisms Review: Patterns and Frameworks Review: Patterns and Frameworks Pattern Provides a common solution to a common problem in a context Analysis/Design Pattern Provides a solution to a narrowly scoped technical problem Provides a fragment of a solution, or a piece of the puzzle Framework Defines the general approach to solving the problem Provides a skeletal solution, whose details may be analysis/design patterns 6 7 Analysis mechanisms provide conceptual sets of services that are used by analysis objects. They offer a convenient shorthand for fairly complex behaviors that will ultimately have to be worried about, but that are out of scope for the analysis effort.their main purpose is to allow us to capture the requirements of these yet-tobe designed services of the system without having to be concerned about the details of the service provider itself. Now we must begin to refine the information gathered on the analysis mechanisms. We discussed analysis mechanisms in Architectural Analysis. Now we will look at design and implementation mechanisms. In this section, we will define what design and implementation mechanisms are and how they map from analysis mechanisms. We will provide abstract patterns of behavior for the mechanisms that we will utilize in the later Design activities. The goal is not to teach you how to identify and design the presented mechanisms, but to be able to produce designs that incorporate those mechanisms. A pattern codifies specific knowledge collected from experience. Patterns provide examples of how good modeling solves real problems, whether you come up with the patterns yourself or you reuse someone else s. Design patterns are discussed in more detail on the next slide. Frameworks differ from analysis and design patterns in their scale and scope. Frameworks describe a skeletal solution to a particular problem that may lack many of the details. These details can be filled in by applying various analysis and design patterns. A framework is a micro-architecture that provides an incomplete template for applications within a specific domain. Architectural frameworks provide the context in which the components run. They provide the infrastructure (plumbing, if you will) that allows the components to co-exist and perform in predictable ways. These frameworks can provide communication mechanisms, distribution mechanisms, error processing capabilities, transaction support, and so forth. Frameworks can range in scope from persistence frameworks that describe the workings of a fairly complex but fragmentary part of an application, to domainspecific frameworks that are intended to be customized (such as Peoplesoft, SanFransisco, Infinity, and SAP). SAP is a framework for manufacturing and finance. 8-6 Copyright IBM Corp Copyright IBM Corp

37 Module 8 - Identify Design Mechanisms What Is a Design Pattern? What Is a Design Pattern? A design pattern provides a scheme for refining the subsystems or components of a software system, or the relationships between them. It describes a commonlyrecurring structure of communicating components that solves a general design problem within a particular context. Erich Gamma et al Design Patterns Elements of Reusable Object-Oriented Software Template Parameters Pattern Name Examples of Pattern Usage Examples of Pattern Usage Pattern Command (behavioral pattern) Abstract factory (creational pattern) Proxy (structural pattern) Observer (behavioral pattern) Example Issue a request to an object without knowing anything about the operation requested or the receiver of the request: for example, the response to a menu item, an undo request, the processing of a time-out Create GUI objects (buttons, scrollbars, windows, etc.) independent of the underlying OS: the application can be easily ported to different environments Handle distributed objects in a way that is transparent to the client objects (remote proxy) Load a large graphical object or any entity object costly to create/initialize only when needed (on demand) and in a transparent way (virtual proxy) When the state of an object changes, the dependent objects are notified. The changed object is independent of the observers. Note: The MVC architectural pattern is an extension of the Observer design pattern 9 8 Design patterns are medium-to-small-scale patterns, smaller in scale than architectural patterns but typically independent of programming language. When a design pattern is bound, it forms a portion of a concrete design model (perhaps a portion of a design mechanism). Design patterns tend, because of their level, to be applicable across domains. 8-8 Copyright IBM Corp Copyright IBM Corp

38 Module 8 - Identify Design Mechanisms Detailing the Command Pattern Detailing the Command Pattern Detailing the Command Pattern (continued) Detailing the Command Pattern (continued) Application Application AskUser(); DoOpen(); OpenCommand + Process() +cmd +menu 1 Menu 0..* MenuItem - label : String 1 Command +items + Clicked() +cmd + Process() +menu 1 Menu 0..* +items MenuItem - label : String 1 Command + Process() + Clicked() cmd.process(); cmd.process(); The problem imagine we want to build a reusable GUI component. To keep it simple, we will limit ourselves to the implementation of generic menus in a windowing system (in such a way that it will be possible to add new menus without having to modify the GUI component). Application: it is the client class, it simulates the application. Menu: to simplify, we will make the assumption that our application has only one menu represented by an association with a multiplicity of 1 and a role name menu. MenuItem: a menu is composed of menu items. Command: this is an abstract class. It has one operation called Process. It is an abstract operation, which means it must be overridden by subclasses of Command. We will now make the assumption that the underlying windowing system requires that we define in MenuItem an operation called Clicked that will be automatically invoked when the user selects the corresponding menu during execution time. The code for Clicked is (using a Java-like pseudo-code): cmd.process(); Suppose now that you want to implement the menu command Open Create a new class called OpenCommand that inherits from Command. This class overrides the operation Process to prompt the user to for the file to open and to open it: AskUser(); DoOpen(); 8-10 Copyright IBM Corp Copyright IBM Corp

39 Module 8 - Identify Design Mechanisms Detailing the Command Pattern (continued) Detailing the Command Pattern (continued) Detailing the Command Pattern (continued) Detailing the Command Pattern (continued) 1. OpenCommand( ) myapp ocmd : OpenCommand menu 2. AddItem("Open...",ocmd) 3. MenuItem("Open...", ocmd) anewitem : MenuItem The user selects the Open menu item A user Initialization 3. AskUser( ) 4. DoOpen( ) 1. Clicked( ) 2. Process( ) themenuitem cmd : Command Application +menu 1 Menu + AddItem(s : String, c : Command) Clicked(): cmd.process(); AskUser(); DoOpen(); MenuItem 0..* - label : String +items + Clicked() + MenuItem(s : String, c : Command) MenuItem(): cmd = c; label = s; OpenCommand + Process() + OpenCommand() - AskUser() - DoOpen() 1 +cmd Command + Process() Look at the dynamic behavior of the system: first, create an interaction diagram showing the initialization of the system. When the system started up, the objects myapp:application and menu:menu were created. Then myapp creates the object ocmd:opencommand (message 1). Then it invokes a new operation from menu called AddItem that takes two arguments: s of type String (the label of the menu item to create) and c of type Command. Note that myapp passes to AddItem, a subclass of Command (message 2). Menu creates a new menu item (message 3). The arguments of the constructor for MenuItem are the same as AddItem. The code of the constructor is straightforward: label = s; cmd = c; It is very important to note that cmd is initialized with a subclass of Command but that MenuItem thinks it is a Command object! This is all the magic of polymorphism! Now, draw a second interaction diagram that will show what happens when the user selects the menu item Open. The Clicked operation is invoked (message 1). Clicked simply executes the Process operation of the associated cmd object. In this case, the cmd object is actually the OpenCommand object (although this is transparent to the MenuItem object). To complete the class diagram, there should be a Uses relationship from Application to OpenCommand to account for the fact that the former creates the latter, and there should be another Uses relationship from Menu to Command as the AddItem operation takes one argument of type Command Copyright IBM Corp Copyright IBM Corp

40 Module 8 - Identify Design Mechanisms Detailing the Command Pattern (continued) Detailing the Command Pattern (continued) app Application CloseCommand OpenCommand Representing Design Patterns in UML Representing Design Patterns in UML A design pattern is a parameterized collaboration: The parameters (stereotype <<role>>) of the collaboration gui Client Invoker ConcreteCommand Command <<role>> Client <<role>> ConcreteCommand Menu MenuItem + Process() <<role>> Invoker com Command Command + Process() So what about reuse? Assign the classes to packages: OpenCommand and Application to app (you have also added a new class, CloseCommand), Menu and MenuItem to gui and Command to com, now add the appropriate dependencies. You have created a reusable set of components (gui and com) independent of the application packages using them! MenuItem can be made an Implementation class only! Only Menu is exported. In the example on the previous slides, the Client role was played by the classes Application and Menu, the Invoker was MenuItem, and the ConcreteCommand was OpenCommand Copyright IBM Corp Copyright IBM Corp

41 Module 8 - Identify Design Mechanisms Describing Analysis Mechanisms Describing Analysis Mechanisms Collect all analysis mechanisms in a list Draw a map of the client classes to the analysis mechanisms Analysis Class Student Schedule CourseOffering Course RegistrationController Analysis Mechanism(s) Persistence, Security Persistence, Security Persistence, Legacy Interface Persistence, Legacy Interface Distribution Identify characteristics of the Analysis mechanisms Categorize Analysis Mechanisms Categorize Analysis Mechanisms Purpose To refine the information gathered on the analysis mechanisms Steps Identify the clients of each analysis mechanism Identify characteristic profiles for each analysis mechanism Group clients according to their use of characteristic profiles Proceed bottom up and make an inventory of the implementation mechanisms that you have at your disposal As we discussed in module 5, analysis mechanisms represent a pattern that constitutes a common solution to a common problem. They can show patterns of structure, patterns of behavior, or both. These mechanisms might show patterns of structure, patterns of behavior, or both. They are used during analysis to reduce the complexity of analysis, and to improve its consistency by providing designers with a shorthand representation for complex behavior. By using mechanisms as placeholders in the architecture, the architecting effort is less likely to become distracted by the details of mechanism behavior. Identify the clients of each analysis mechanism. Scan all clients of a given analysis mechanism, looking at the characteristics they require for that mechanism. For example, a number of analysis objects might make use of a persistence mechanism, but their requirements on this can widely vary: A class that has one thousand persistent instances has significantly different persistence requirements than a class that has four million persistent instances. Similarly, a class whose instances must provide sub-millisecond response to instance data requires a different approach than a class whose instance data is accessed through batch applications. Identify characteristic profiles for each analysis mechanism. There may be widely varying characteristics profiles, providing varying degrees of performance, footprint, security, economic cost, and so forth. Each analysis mechanism is different so different characteristics will apply to each. Many mechanisms require estimates of the number and size of instances to be managed. The movement of large amounts of data through any system creates tremendous performance issues that must be dealt with. Group clients according to their use of characteristic profiles. Identify a design mechanism for groups of clients that seem to share a need for an analysis mechanism with a similar characteristics profile. These groupings provide an initial cut at the design mechanisms. An example analysis mechanism, "inter-process communication," might map onto a design mechanism "object request broker." Different characteristic profiles will lead to different design mechanisms that emerge from the same analysis mechanism. The simple persistence mechanism in analysis will give rise to a number of persistence mechanisms in design: in-memory persistence, file-based, databasebased, distributed, and so forth Copyright IBM Corp Copyright IBM Corp

42 Module 8 - Identify Design Mechanisms Identify Design Mechanisms: Steps Identify Design Mechanisms: Steps Design and Implementation Mechanisms Design and Implementation Mechanisms Categorize clients of analysis mechanisms Documenting architectural mechanisms Analysis Mechanism (Conceptual) Design Mechanism (Concrete) Implementation Mechanism (Actual) Legacy Data Persistency RDBMS JDBC New Data Persistency OODBMS ObjectStore Distribution Remote Method Invocation (RMI) Java 1.2 from Sun Design mechanisms provide an abstraction of the implementation mechanisms, bridging the gap between analysis mechanisms and implementation mechanisms. The use of abstract architectural mechanisms during Design allows us to consider how we are going to provide architectural mechanisms without obscuring the problem-athand with the details of a particular mechanism. It also allows us to potentially substitute one specific implementation mechanism for another without adversely affecting the design. During Architecture Analysis, you identified the key architectural mechanisms that might be required to solve the problem. Now it is time to refine these and incorporate the decisions made about our implementation. Design mechanism assumes some details of the implementation environment, but it is not tied to a specific implementation (as is an implementation mechanism). Examples of design mechanisms include: Persistency: RDBMS, OODBMS, flash card, in-memory storage. Inter-process communication (IPC): Shared memory, function-call-like IPC, semaphore-based IPC. Implementation mechanisms are used during the Implementation process. They are refinements of design mechanisms, and they specify the exact implementation of the mechanism. They are are bound to a certain technology, implementation language, vendor, etc. Some examples of implementation mechanisms include the actual programming language, COTS products, database (Oracle, Sybase), and the interprocess communication/distribution technology in use (COM/DCOM, CORBA). The above slide shows the architectural mechanism decisions that have been made for each example. For RDBMS persistency (that is, legacy data access), JDBC was chosen. For OODBMS persistency, ObjectStore was chosen, and for Distribution, RMI was chosen. The JDBC mechanism is discussed later in this module. Information on the ObjectStore and RMI mechanisms are provided in the Additional Information Appendix Copyright IBM Corp Copyright IBM Corp

43 Module 8 - Identify Design Mechanisms Review: Documenting Architectural Mechanisms Review: Documenting Architectural Mechanisms Review: Course Registration Analysis Mechanisms Review: Course Registration Analysis Mechanisms Architectural mechanisms can be treated as patterns (i.e., parameterized collaboration) Template Parameters Pattern Name Persistence Distribution Security Legacy Interface Structural Aspect Behavioral Aspect Documented in Design Guidelines Design patterns as parameterized collaborations were discussed in the Architectural Analysis module. Architectural mechanisms can be treated as patterns and documented the same way (that is, as parameterized collaborations). Like the patterns discussed in Architectural Analysis, an architectural mechanism parameterized collaboration has a structural aspect and a behavioral aspect. The structural part consists of the classes whose instances implement the mechanism and their relationships (the static view). The behavioral aspect describes how the instances collaborate (that is, send messages to each other) to implement the mechanism (the dynamic view). The role of the architect is to decide upon and validate mechanisms by building or integrating them, as well as by verifying that they do the job. The architect must then consistently impose the mechanisms upon the rest of the system design. Thus, for each architectural mechanism the architect must provide a static and a dynamic view, accompanied by rules of use. The mechanisms, the mapping between them, and details regarding their use, must be documented in the Design Guidelines specific to the project, not in the Software Architecture Document (SAD). The SAD captures actual architectural choices made for a system on the basis of nonfunctional requirements and functional requirements. The Design Guidelines document provides for design not yet done. In many organizations, the design guidelines exist as an organizational asset independent of particular projects. It represents the collected reusable design wisdom for that organization in a particular domain. It might then require refinement to suit a project. Therefore, the SAD is the architectural representation (or at least the most significant parts of it). The Design Guidelines cover how to do design, in a very specific, not just conceptual, way. The above slide lists the selected analysis mechanisms for the Course Registration System. Persistency: A means to make an element persistent (that is, exist after the application that created it ceases to exist). Distribution: A means to distribute an element across existing nodes of the system. Security: A means to control access to an element. Legacy Interface: A means to access a legacy system with an existing interface. These mechanisms are also documented in the Payroll Architecture Handbook, Architectural Mechanisms section. Next, we will discuss the design mechanisms for persistence, distribution, and security Copyright IBM Corp Copyright IBM Corp

44 Module 8 - Identify Design Mechanisms Mechanism: Persistency: RDBMS: JDBC Mechanism: Persistency: RDBMS: JDBC Example: Persistency: RDBMS: JDBC Example: Persistency: RDBMS: JDBC Persistence characteristics: Granularity Volume Duration Access mechanism Access frequency (creation/deletion, update, read) Reliability <<role>> PersistencyClient (from SamplePersistency Client) <<role>> DBClass create() : PersistentClass read(searchcriteria : String) : PersistentClassList update(c : PersistentClass) delete(c : PersistentClass) Roles to be filled by the designer applying the mechanism 1 1 <<role>> PersistentClassList (from SamplePersistentClass) new() add(c: PersistentClass) 1 0..* 0..* <<role>> PersistentClass (from SamplePersistentClass) getdata() setdata() command() new() DriverManager (from java.sql) getconnection(url, user, pass) : Connection Note: JDBC is the standard Java API for talking to a SQL database. ResultSet (from java.sql) Statement (from java.sql) Connection (from java.sql) getstring() : String executequery(sql : String) : ResultSet executeupdate(sql : String) : int createstatement() : Statement These characteristics were first introduced in Architectural Analysis. When we described the persistency architectural mechanism, we used the following characteristics; Persistency: For all classes whose instances might become persistent, we need to identify: Granularity: What is the range of the persistent objects? Volume: How many objects must be kept persistent? Duration: How long must the persistent objects be kept? Access mechanism: How is a given object uniquely identified and retrieved? Access frequency: Are the objects more or less constant? Are they permanently updated? Reliability: Can the objects survive a crash of the process, the processor, or the whole system? The next few slides demonstrate the pattern of use of the persistent mechanism chosen for the RDBMS classes in our example: JDBC. The above diagram is the static view. For JDBC, a client works with a DBClass to read and write persistent data. The DBClass is responsible for accessing the JDBC database using the DriverManager class. Once a database Connection is opened, the DBClass can then create SQL statements that will be sent to the underlying RDBMS and executed using the Statement class. The Statement is what talks to the database. The result of the SQL query is returned in a ResultSet object. The DBClass is the one responsible for making another class instance persistent. It understands the OO-to-RDBMS mapping and has the behavior to interface with the RDBMS. The DBClass flattens the object, writes it to the RDBMS, reads the object data from the RDBMS, and builds the object. Every class that is persistent has a corresponding DBClass. The PersistentClassList is used to return a set of persistent objects as a result of a database query (for example, DBClass.read()). The <<role>> stereotype was used for anything that should be regarded as a placeholder for the actual design element to be supplied by the developer. This convention makes it easier to apply the mechanism, because it is easier to recognize what the designer must supply Copyright IBM Corp Copyright IBM Corp

45 Module 8 - Identify Design Mechanisms Example: Persistency: RDBMS: JDBC: Initialize Example: Persistency: RDBMS: JDBC: Initialize Example: Persistency: RDBMS: JDBC: Create Example: Persistency: RDBMS: JDBC: Create : PersistencyClient : DBClass : PersistentClass : Connection : Statement : DBClass : DriverManager 1. getconnection(url, user, pass) 1. create( ) 1.1. New() 1.2. getdata( ) 1.3. createstatement( ) 1.4. executeupdate(string) Initialization must occur before any persistent class can be accessed. To initialize the connection to the database, the DBClass must load the appropriate driver by calling the DriverManager getconnection() operation with a URL, user, and password. getconnection() attempts to establish a connection to the given database URL. The DriverManager attempts to select an appropriate driver from the set of registered JDBC drivers. Parameters: url: A database url of the form jdbc:subprotocol:subname. This URL is used to locate the actual database server. It is not Web-related in this instance. user: The database user on whose behalf the connection is being made. password: The user's password. It returns a connection to the URL. To create a new class, the persistency client asks the DBClass to create the new class. The DBClass creates a new instance of PersistentClass with default values. The DBClass then creates a new Statement using the Connection class createstatement() operation. The Statement is executed, and the data is inserted into the database Copyright IBM Corp Copyright IBM Corp

46 Module 8 - Identify Design Mechanisms What Is a Combined Fragment? What Is a Combined Fragment? A construct within an interaction that comprises an operator keyword and one or more interaction operands, each of which is a fragment of an interaction. It is shown as a nested region within a sequence diagram. Client Object :Client interaction operand Supplier Object :Supplier What is an Interaction Operand? What is an Interaction Operand? Each fragment comprises one or more interaction operands, each a subfragment of the interaction. The number of operands depends on the type of combined fragment. For example, a loop has one operand (the loop body) and a conditional has one or more operands (the branches of the conditional). An operand is a nested fragment of an interaction. Each operand covers the lifelines covered by the combined fragment or a subset of them. 27 The general notation for a combined fragment is a rectangle with a small pentagon in the upper left corner containing the interaction operand. The rectangle is nested within its containing fragment or within the sequence diagram as a whole. 26 The value of the Interaction Operand is given as text in a small compartment in the upper left corner of the Combined Fragment frame (alt, assert, break, consider, critical, ignore, loop, neg, opt, par, seq, strict). Multiple interaction operands will be separated by a dashed horizontal line and together make up the framed Combined Fragment Copyright IBM Corp Copyright IBM Corp

47 Module 8 - Identify Design Mechanisms What is an Interaction Expression? What is an Interaction Expression? A specification of the range of number of iterations of a loop. Range can be specified with minimum and maximum values A guard condition, enclosed in square brackets, can be included on a lifeline. Client Object Supplier Object Example: Persistency: RDBMS: JDBC: Read Example : Persistency: RDBMS: JDBC: Read : PersistencyClient : DBClass : Connection : Statement : ResultSet : PersistentClassList 1. read(string) The criteria used to access data for the persistent class 1.1. createstatement( ) Returns a Statement 1.2. executequery(string) 1.4. new( ) loop [for each class from execute query] The SQL statement built by the DBClass using the given criteria is passed to executequery() 1.5. new() Create a list to hold all retrieved data 1.3 // executequery() : PersistentClass :Client Interaction Expression :Supplier loop [for each attribute in class] 1.6. getstring( ) 1.7. setdata( ) loop (range) [guard exp] 1: PerformResponsibility 1.8. add(persistentclass) The range on the number of iterations of a loop are included in parentheses as part of the tag after the keyword loop: loop Minimum = 0, unlimited maximum loop (repeat) Minimum = maximum = repeat loop (minimum, maximum) Explicit minimum and maximum bounds In addition to the bounds, a Boolean expression can be included as a guard on a lifeline. As long as the expression is true, the loop will continue to iterate. To read a persistent class, the persistency client asks the DBClass to read. The DBClass creates a new Statement using the Connection class createstatement() operation. The Statement is executed, and the data is returned in a ResultSet object. The DBClass then creates a new instance of the PersistentClass and populates it with the retrieved data. The data is returned in a collection object, an instance of the PersistentClassList class. Note: The string passed to executequery() is not the exact same string as the one passed into the read(). The DBClass builds the SQL query to retrieve the persistent data from the database, using the criteria passed into the read(). This is because we do not want the client of the DBClass to have the knowledge of the internals of the database to create a valid query. This knowledge is encapsulated within DBClass Copyright IBM Corp Copyright IBM Corp

48 Module 8 - Identify Design Mechanisms Example: Persistency: RDBMS: JDBC: Update Example: Persistency: RDBMS: JDBC: Update Example: Persistency: RDBMS: JDBC: Delete Example: Persistency: RDBMS: JDBC: Delete : PersistencyClient : DBClass : PersistentClass : Connection : Statement : PersistencyClient : DBClass : Connection : Statement 1. update(persistentclass) 1.1. getdata( ) 1. delete(persistentclass) 1.2. createstatement( ) 1.3. executeupdate(string) 1.1. createstatement( ) 1.2. executeupdate(string) execute SQL statement execute SQL statement To update a class, the persistency client asks the DBClass to update. The DBClass retrieves the data from the given PersistentClass object, and creates a new Statement using the Connection class createstatement() operation. Once the Statement is built the update is executed and the database is updated with the new data from the class. Remember that it is the DBClass s job to flatten the PersistentClass and write it to the database. That is why it must be retrieved from the given PersistentClass before creating the SQL Statement. Note: In the above mechanism, the PersistentClass must provide access routines for all persistent data so that DBClass can access them. This provides external access to certain persistent attributes that would have otherwise have been private. This is a price you have to pay to pull the persistence knowledge out of the class that encapsulates the data. To delete a class, the persistency client asks the DBClass to delete the PersistentClass. The DBClass creates a new Statement using the Connection class createstatement() operation. The Statement is executed, and the data is removed from the database Copyright IBM Corp Copyright IBM Corp

49 Module 8 - Identify Design Mechanisms Incorporating JDBC: Steps Incorporating JDBC: Steps 1. Provide access to the class libraries needed to implement JDBC Provide java.sql package 2. Create the necessary DBClasses Assign one DBClass per persistent class 3. Incorporate DBClasses into the design Allocate to package/layer Add relationships from persistency clients 4. Create/Update interaction diagrams that describe: Database initialization Persistent class access: Create, Read, Update, Delete Deferred Example: Incorporating JDBC Example: Incorporating JDBC Sample Persistency Client Package DriverManager (from java.sql) Statement (from java.sql) java.sql Connection (from java.sql) ResultSet (from java.sql) The above is a summary of the steps that can be used to implement the RDBMS persistency mechanism (JDBC). The italicized text on the slide describes the architectural decisions made in regards to JDBC for our Course Registration example. Here are some explanations: The java.sql package contains the design elements that support the RDBMS persistency mechanism. It will be depended on by the package(s) in which the DBClasses are placed. There is one DBClass per persistent class. Once created, the DBClasses must be incorporated into the existing design. They must be allocated to a package/layer. Once the DBClasses have been allocated to packages/layers, the relationships to the DBClasses from all classes requiring persistence support will need to be added. The interaction diagrams provide a means to verify that all required database functionality is supported by the design elements. The sample interaction diagrams provided for the persistency architectural mechanisms during Identify Design Mechanisms should serve as starting points for the specific interaction diagrams defined in detailed design. In Identify Design Mechanisms, make sure that the architecture has the necessary infrastructure (that is, that we have access to the class libraries that are needed to implement JDBC). The definition of the actual DBClasses and the development of the detailed interaction diagrams is deferred until detailed design. The following changes must be made to the Course Registration Model to incorporate the JDBC persistency mechanisms: Access must be provided to the java.sql package that contains the design elements that support the RDBMS persistency mechanism. The packages where the created DBClasses reside must have a dependency on the java.sql package. Remember, there will be a DBClass for every RDBMS persistent class. The creation of the DB classes and the decision as to where they reside in the architecture will be determine during detailed design (for example, Use-Case and Subsystem Design) Copyright IBM Corp Copyright IBM Corp

50 Review Review: Identify Design Mechanisms What does an analysis mechanism do? What is a pattern? What makes a framework different from a pattern? Why should you categorize analysis mechanisms? Identify the steps. Module 9 Describe the Run-Time Architecture IBM Software Group Mastering Object-Oriented Analysis and Design with UML 2.0 Module 9: Describe the Run-time Architecture 34 1 Topics Describe the Run-time Architecture Overview What Is Concurrency? Identifying Processes and Threads Creating and Destroying Processes and Threads Mapping Processes onto the Implementation Design Elements-to-Processes Strategies Review Copyright IBM Corp Copyright IBM Corp

51 Module 9 - Describe the Run-Time Architecture Objectives: Describe the Run-time Architecture Objectives: Describe the Run-time Architecture Describe the Run-time Architecture in Context Describe the Run-time Architecture in Context Define the purpose of the Describe the Run-time Architecture activity and when in the lifecycle it is performed Demonstrate how to model processes and threads Explain how processes can be modeled using classes, objects and components Define the rationale and considerations that support architectural decisions Describe the Run-time Architect Architecture [Early Elaboration Iteration] Define a Candidate Architecture Refine the Architecture Design Components [Inception Iteration (Optional)] Perform Architectural Synthesis Analyze Behavior Design the Database (Optional) 2 3 The Describe the Run-time Architecture activity focuses on the identification and modeling of the independent system of control of flows (for example, process and threads) and the ways in which they communicate. The focus of the Describe the Run-time Architecture activity is on developing the Process View of the architecture. In this module, you will describe what is performed in Describe the Run-time Architecture but will not describe how to do it. Such a discussion is of interest in an architecture course, which this course is not. The goal of this module is to give the student an understanding of how to model the Process View using the UML. A comprehension of the rationale and considerations that support the architectural decisions is needed in order to understand the architecture, which is the framework in which designs must be developed. As you may recall, the above diagram illustrates the workflow that we are using in this course. It is a tailored version of the Analysis and Design core workflow of the Rational Unified Process. Describe the Run-time Architecture is an activity in the Refine the Architecture workflow detail. At this point, the subsystems, their interfaces, and their dependencies is normally defined. The initial design classes and the packages in which they belong have also been defined. In Describe the Run-time Architecture, the independent threads of control are identified, and the design elements (subsystems and classes) are mapped to these threads of control. The focus is on the Process View of the architecture. If the system under development needs only to run one process, then there is no need for a separate Process View. In such a case, Describe the Run-time Architecture can be skipped. 9-2 Copyright IBM Corp Copyright IBM Corp

52 Module 9 - Describe the Run-Time Architecture Describe the Run-time Architecture Overview Describe the Run-time Architecture Overview Key Concepts: The Process View Key Concepts: The Process View Logical View Implementation View Supplementary Specifications Analysts/Designers Structure Use-Case View Programmers Software management Describe the Run-time Architecture Software Architecture Document Process View System integrators Performance, scalability, throughput End-user Functionality Deployment View System engineering System topology, delivery, installation, communication Design Model The Process View is an architecturally significant slice of the processes and threads of the Design Model. 5 The architect performs the Describe the Run-time Architecture, once per iteration. Purpose To analyze concurrency requirements, to identify processes, identify interprocess communication mechanisms, allocate inter-process coordination resources, identify process lifecycles, and distribute model elements among processes. Input Artifacts Supplementary Specifications Design Model Software Architecture Document Resulting Artifacts Software Architecture Document Design Model 4 In Describe the Run-time Architecture, we will be concentrating on the Process View. Before we discuss the details of what occurs in Describe the Run-time Architecture, you need to review what the Process View is. The above slide describes the model Rational uses to describe the software architecture. For each view, the stakeholder interested in it and the concern addressed in it are listed. The Process View describes the planned process structure of the system. It is concerned with dynamic, run-time decomposition and takes into account some nonfunctional requirements, such as performance and availability. It also includes some derived requirements resulting from the need to spread the system onto several computers. In the Process View, the system is decomposed into a set of independent tasks and threads, processes, and process groups. The Process View describes process interaction, communication, and synchronization. 9-4 Copyright IBM Corp Copyright IBM Corp

53 Module 9 - Describe the Run-Time Architecture What Is Concurrency? What Is Concurrency? Example of concurrency at work: Parallel roads require little coordination Two-way roads require some coordination for safe interaction Intersections require careful coordination Parallel Two-way Intersections Why Are We Interested in Concurrency? Why Are We Interested in Concurrency? Software might need to respond to seemingly random externally generated events Performing tasks in parallel can improve performance if multiple CPUs are available Example: Startup of a system Control of the system can be enhanced through concurrency 7 Concurrency is the tendency for things to happen at the same time in a system. Concurrency is a natural phenomenon, of course. In the real world, at any given time many things are happening simultaneously. When we design software to monitor and control real-world systems, we must deal with this natural concurrency. When dealing with concurrency issues in software systems, you must consider two important aspects: Being able to detect and respond to external events occurring in a random order. Ensuring that these events are responded to in some minimum required interval. If each concurrent activity evolved independently, in a truly parallel fashion, managing them would be relatively simple: we could just create separate programs to deal with each activity. However, this is not the case. The challenges of designing concurrent systems arise mainly because of the interactions that happen between concurrent activities. When concurrent activities interact, some sort of coordination is required. Vehicular traffic provides a useful analogy. Parallel traffic streams on different roadways having little interaction cause few problems. Parallel streams in adjacent lanes require some coordination for safe interaction, but a much more severe type of interaction occurs at an intersection, where careful coordination is required. 6 Some of the driving forces behind finding ways to manage concurrency are external. That is, they are imposed by the demands of the environment. In real-world systems, many things are happening simultaneously and must be addressed in real-time by software. To do so, many real time software systems must be reactive. They must respond to externally generated events that might occur at somewhat random times, in somewhat random order, or both. Designing a conventional procedural program to deal with these situations is extremely complex. It can be much simpler to partition the system into concurrent software elements to deal with each of these events. The key phrase here is can be, since complexity is also affected by the degree of interaction between the events. There also can be internally inspired reasons for concurrency. For example, performing tasks in parallel can substantially speed up the computational work of a system if multiple CPUs are available. Even within a single processor, multitasking can dramatically speed things up by preventing one activity from blocking another while waiting for I/O. A common situation in which this occurs is during the startup of a system. There are often many components, each of which requires time to be made ready for operation. Performing these operations sequentially can be painfully slow. Controllability of the system can also be enhanced by concurrency. For example, one function can be started, stopped, or otherwise influenced in midstream by other concurrent functions something extremely difficult to accomplish without concurrent components. 9-6 Copyright IBM Corp Copyright IBM Corp