Architectural Analysis These slides are derived from IBM/Rational slides from courses on UML and object-oriented design and analysis. Copyright to the.

Architectural Analysis

These slides are derived from IBM/Rational slides from courses on UML and object-oriented design and

analysis.Copyright to the original slides resides with

IBM/Rational. They are used here, in this course, under password protection limited to students

enrolled in the course, with permission of the owners, but are not to be published or further distributed.

What Is Architecture?

• Software architecture encompasses a set of significant decisions about the organization of a software system.– Selection of the structural elements and their

interfaces by which a system is composed– Behavior as specified in collaborations

among those elements– Composition of these structural and

behavioral elements into larger subsystems– Architectural style that guides this

organization

Grady Booch, Philippe Kruchten, Rich Reitman, Kurt Bittner; Rational(derived from Mary Shaw)

Architecture Constrains Design and Implementation

• Architecture involves a set of strategic design decisions, rules or patterns that constrain design and construction.

Architecture decisions are the most fundamental decisions, and changing them will have significant effects.

Architecture

Design

Implementation

Code`1`

Software Architecture: The “4+1 View” Model

Process View Deployment View

Logical View

Use-Case View

Implementation View

End-userFunctionality

Programmers

Software management

Performance, scalability, throughputSystem integrators System topology, delivery,

installation, communication

System engineering

Analysts/Designers

Structure

Analysis and Design Workflow

Analysis

Design

[Early Elaboration Iteration]

[Inception Iteration (Optional)]

Define a CandidateArchitecture

PerformArchitecturalSynthesis

Analyze Behavior

Refine theArchitecture

DesignComponents

Design theDatabase

(Optional)

Analysis and Design Activity Overview

Architect

Designer

Software Architect’s Responsibilities

Architect

Software ArchitectureDocument

• The Software Architect leads and coordinates technical activities and artifacts.

Reference Architecture

Analysis Model

Design Model

Deployment ModelImplementation Model

Designer’s Responsibilities

DesignerUse-Case Realization

Package Class/Subsystems

• The designer must know use-case modeling techniques, system requirements, and software design techniques.

Review: Analysis and Design Is Use-Case Driven

• Use cases defined for a system are the basis for the entire development process.

• Benefits of use cases:– Concise, simple, and understandable by a wide

range of stakeholders.– Help synchronize the content of different models.

Withdraw Money

Check Balance

Customer

What Is a Use-Case Realization?

Class DiagramsUse Case

Communication Diagrams

Use-Case Model Design Model

Use Case Use-Case Realization

Sequence Diagrams

(Traceability)

Analysis and Design in an Iterative Process

Iteration n Iteration n + 1

Use Case AScenarios 1 & 2

Use-Case Realization A

Start of iteration

End of iteration

Use Case B Scenario 1

Use-Case Realization A

Use Case AScenario 3

Use-Case Realization B

Review

• What is the purpose of the Analysis and Design Discipline?

• What are the input and output artifacts?

• Name and briefly describe the 4+1 Views of Architecture.

• What is the difference between Analysis and Design?

• What is architecture?

ARCHITECTURAL ANALYSIS

KEY CONCEPTS

Architectural Analysis in Context[Early

Elaboration Iteration]



PerformArchitectural

Synthesis

Analyze Behavior


DesignComponents

Design theDatabase

(Optional)

ArchitectureAnalysis` Architect

Architectural Analysis Overview

SupplementarySpecification

Glossary

Use-Case Model

ArchitecturalAnalysis

Design Model

Reference Architecture

Deployment Model

VisionDocument

Software Architecture Doc

Project-SpecificGuidelines

Architectural Analysis Steps

• Key Concepts• Define the High-Level Organization of

Subsystems• Identify Analysis mechanisms• Identify Key Abstractions• Create Use-Case Realizations• Checkpoints

• A package is a general-purpose mechanism for organizing elements into groups.

• It is a model element that can contain other model elements.

• A package can be used:– To organize the model under development.– As a unit of configuration management.– To cope with complexity.

Review: What Is a Package?

UniversityArtifacts

• Packages can be related to one another using a dependency relationship.

• Dependency Implications– Changes to the Supplier package may affect

the Client package.– The Client package cannot be reused

independently because it depends on the Supplier package.

Package Relationships: Dependency

Client Package Supplier Package

Dependency relationship

Package Diagram for 5 Layers

A package diagram shows packages only

C

A

B

Hierarchy should be acyclic

A

B

C

A'

Circular dependencies make it impossible to reuse one package

without the other.

Avoiding Circular Dependencies

A

B



Subsystems• Identify Analysis mechanisms• Identify Key Abstractions• Create Use-Case Realizations• Checkpoints

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

Structural Aspect Behavioral Aspect

What Is a Design Pattern?• A solution to a common design problem.– Describes a common design problem– Describes the solution to the problem– Discusses the results and trade-offs of

applying the pattern• Provides the capability to reuse successful

designs.

ParameterizedCollaboration

Pattern Name

TemplateParameters

What Is an Architectural Pattern?

• An architectural pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them – Buschman et al, “Pattern-Oriented Software Architecture — A System of Patterns”– Layers– Model-view-controller (M-V-C)– Pipes and filters– Blackboard

EVOLVING THE ANALYSIS MODELS INTO DESIGN MODELS

Factoring

• Creating modules that account for similarities and differences between units of interest

• New classes– Generalization– Aggregation

• Abstracting• Refinement

Partitions and Collaborations

• Creating “subsystems” or larger units

• Grouping units that collaborate• May have collaboration among units

or partitions• The more messages or contracts

between objects, the more likely they are in the same partition

Layers

• Consider system environment information to help evolve the analysis model

• Model-view-controller (MVC) architecture

• Separating application logic from user interface logic

Typical Layering Approach

General functionality

Specific functionality

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.

Application SubsystemsApplication Subsystems

Business-SpecificBusiness-Specific

MiddlewareMiddleware

System SoftwareSystem Software

Example: Layers

Application

Presentation

Session

Transport

Network

Data Link

Physical

Layer 7

Layer 6

Layer 5

Layer 4

Layer 3

Layer 2

Layer 1

Provides miscellaneous protocols for common activities

Structure information and attaches semantics

Provides dialog control and synchronization facilities

Breaks messages into packets and guarantees delivery

Selects a route from send to receiver

Detects and corrects errors in bit sequences

Transmits bits: velocity, bit-code, connection, etc.

Architectural Pattern: Layers

Equipment andEquipment andcustomer-specificcustomer-specificcodecode

Processes and other Processes and other application codeapplication code

Major abstractions, Major abstractions, classes, etc.classes, etc.

Mechanisms, Mechanisms, servicesservices

H/W specific code, O/S H/W specific code, O/S specific code, general-specific code, general-purpose code (for purpose code (for example, ORB, MQS)example, ORB, MQS)

55

44

33

22

11

ApplicationApplication

Application FrameworkApplication Framework

InfrastructureInfrastructure

Dennis et al. : 5 Layers

1. Foundation2. Problem Domain3. Data Management4. Human-Computer Interaction5. Physical Architecture

Are these in a logical order?

Layering Considerations

• Level of abstraction– Group elements at the same level of abstraction

• Separation of concerns– Group like things together– Separate disparate things– Application vs. domain model elements

• Resiliency – Loose coupling– Concentrate on encapsulating change– User interface, business rules, and retained data

tend to have a high potential for change

Modeling Architectural Layers

• Architectural layers can be modeled using stereotyped packages.

• <<layer>> stereotype

Package Name<<layer>>

Class<<stereotype>>

What Are Stereotypes?• Stereotypes define a new model element

in terms of another model element.• Sometimes you need to introduce new

things that speak the language of your domain and look like primitive building blocks.

Stereotype

Example: High-Level Organization of the Model

Application<<layer>>

Business Services <<layer>>



the model• Identify Analysis mechanisms• Identify Key Abstractions• Create Use-Case Realizations• Checkpoints

Architect

SupplementarySpecification

Use-Case Model

MechanismsCOTS ProductsDatabasesIPC Technology, etc.

“realized by client classes using”

“responsible for”

“constrained by”

Required Functionality

Implementation Environment

What Are Architectural Mechanisms?

Architectural Mechanism Categories

• Analysis mechanisms (conceptual)• Design mechanisms (concrete)• Implementation mechanisms (actual)

Why Use Analysis Mechanisms?

Oh no! I found a group of classes that has persistent data. How am I supposed to design these things if I don’t even know what database we are going to be using?

That is why we have a persistence analysis mechanism. We don’t know enough yet, so we can bookmark it and come back to it later.

Analysis mechanisms 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.

Sample Analysis Mechanisms

• Persistency• Communication (IPC and RPC)• Message routing • Distribution• Transaction management • Process control and synchronization

(resource contention)• Information exchange, format conversion• Security • Error detection / handling / reporting• Redundancy • Legacy Interface

Examples of Analysis Mechanism Characteristics

• Persistency mechanism– Granularity– Volume– Duration– Access mechanism– Access frequency (creation/deletion, update,

read)– Reliability

• Inter-process Communication mechanism– Latency– Synchronicity– Message size– Protocol

Example: Analysis Mechanism Characteristics (continued)

• Legacy interface mechanism– Latency– Duration– Access mechanism– Access frequency

• Security mechanism– Data granularity– User granularity – Security rules– Privilege types

• Others

• Collect all analysis mechanisms in a list

• Draw a map of classes to analysis mechanisms

• Identify characteristics of analysis mechanisms

• Model using collaborations

Describing Analysis Mechanisms

Classes

Parsing

Authentication

Communication

Persistency

Analysis Mechanisms

Flight

Aircraft

Mission

Schedule

Route

Load

Example: Course Registration Analysis Mechanisms

Security Legacy Interface

Persistence Distribution



the model• Identify Analysis mechanisms• Identify Key Abstractions• Create Use-Case Realizations• Checkpoints

What Are Key Abstractions?• A key abstraction is a concept, normally

uncovered in Requirements, that the system must be able to handle

• Sources for key abstractions

Domain knowledge Requirements Glossary Domain Model, or the Business

Model (if one exists)

Defining Key Abstractions• Define analysis classes• Model analysis classes and

relationships on class diagrams– Include a brief description of

an analysis class

• Map analysis classes to necessary analysis mechanisms

Example: Key AbstractionsStudentProfessor

Schedule

CourseCatalog CourseCourseOffering


Key Concepts Define the High-Level Organization of the

model Identify Analysis mechanisms Identify Key Abstractions Create Use-Case Realizations Checkpoints

Review: What is a Use-Case Realization?

Class DiagramsUse Case

Communication Diagrams

Use-Case Model Design Model

Use Case Use-Case Realization

Sequence Diagrams

The Value of Use-Case Realizations

• Provides traceability from Analysis and Design back to Requirements

• The Architect creates the Use-Case Realization

Use Case

Analysis & Design(Design Model)

Requirements(Use-Case Model)

Use-Caserealization


Key Concepts Define the High-Level Organization of the

model Identify Analysis mechanisms Identify Key Abstractions Create Use-Case Realizations Checkpoints

Checkpoints• General– Is the package partitioning and

layering done in a logically consistent way?

– Have the necessary analysis mechanisms been identified?

• Packages– Have we provided a

comprehensive picture of the services of the packages in upper-level layers?

Checkpoints (continued)• Classes– Have the key entity classes and

their relationships been identified and accurately modeled?

– Does the name of each class clearly reflect the role it plays?

– Are the key abstractions/classes and their relationships consistent with the Business Model, Domain Model, Requirements, Glossary, etc.?

Review: Architectural Analysis

• What is the purpose of Architectural Analysis?

• What is a package? • What is a layered architecture? Give

examples of typical layers.• What are analysis mechanisms? Give

examples.• What key abstractions are identified

during Architectural Analysis? Why are they identified here?

Building Package Diagrams

1. Set the context2. Cluster classes together based on

shared relationships3. Model clustered classes as a package4. Identify dependency relationships

among packages5. Place dependency relationships

between packages

DESIGN STRATEGIES

Custom Development

• Allows for meeting highly specialized requirements

• Allows flexibility and creativity in solving problems

• Easier to change components• Builds personnel skills• May tax firm’s resources• May add significant risk

Packaged Software

• Software already written• May be more efficient• May be more thoroughly tested and proven• May range from components to tools to

whole enterprise systems• Must accept functionality provided• May require change in how the firm does

business• May require significant “customization” or

“workarounds”

System Integration

• The process of combining packages, legacy systems, and new software

• Key challenge is integrating data• Write data in the same format• Revise existing data formats• Develop “object wrappers”

Outsourcing

• Hire external firm to create system• May have more skills• May extend existing resources• Never outsource what you don’t

understand• Carefully choose vendor• Prepare contract and payment style

carefully

Selecting a Design Strategy

• Business need• In-house experience• Project skills• Project management• Time frame

Selecting a Design Strategy

DEVELOPING THE ACTUAL DESIGN

The Alternative Matrix

• Combines several feasibility analyses into one grid

• Revisits technical, economic, and organizational feasibility

Request for Proposals

• Description of the system you propose to be built

• Vendors, developers, service providers respond with proposals including how they will address needs as well as stating cost and time requirements.

Summary

• Verifying and Validating the Analysis Models

• Evolving the Analysis Models into Design Models

• Packages and Package Diagrams• Design Strategies• Developing the Actual Design

IBM Software Group

®

Mastering Object-Oriented Analysis and Design with UML 2.0Module 7: Identify Design Elements

Objectives: Identify Design Elements

• 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 in Context[Early

Elaboration Iteration]



PerformArchitecturalSynthesis

Analyze Behavior


DesignComponents

Design theDatabase

(Optional)Identify DesignElementsArchitect

SupplementarySpecifications

Identify Design

Elements

SoftwareArchitectureDocument

Design Model

Identify Design Elements Overview

Analysis Model

Project SpecificGuidelines

Identify Design Elements Steps

• Identify classes and subsystems• Identify subsystem interfaces• Update the organization of the

Design Model• Checkpoints


Identify classes and subsystems Identify subsystem interfaces Identify reuse opportunities Update the organization of the Design Model Checkpoints

Analysis Classes

From Analysis Classes to Design ElementsAnalysis Classes Design Elements

<<boundary>>

<<control>>

<<entity>>

<<boundary>>

Many-to-Many Mapping

Subsystem<<subsystem>>

Subsystem<<subsystem>>

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 …

• What is a class?– A description of a set of objects that share

the same responsibilities, relationships, operations, attributes, and semantics

• What is a package?– A general purpose mechanism for

organizing elements into groups– A model element which can contain other

model elements

Review: Class and Package

Package Name

Class Name

• 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– Represent the existing products and services the system uses

Package C

Group Design Classes in Packages

Package B

Package A

Packaging Tips: Boundary ClassesIf 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

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)

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

PackageB

PackageA

Public visibility

Private visibility

Only public classes can be referenced

outside of the owning package

OO Principle: Encapsulation

Package Dependencies: Package Element Visibility

A

B

+ Class A1

+ Class A2

+ Class A3

+ Class B1

- Class B2

A

B

X

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

A B

Upper Layer

Lower Layer

C

X

X = Coupling violation

X

Example: Registration Package

MainRegistrarForm

1

11

MainStudentForm

1

RegisterForCoursesForm<<boundary>>

0..10..1

11

CloseRegistrationForm<<boundary>>

0..10..1

CloseRegistrationController<<control>>

RegistrationController<<control>>

1

FulltimeStudent<<entity>>

ParttimeStudent<<entity>> PrimaryScheduleOfferingInfo

<<entity>>

ScheduleOfferingInfo<<entity>>

Student<<entity>>

Example: University Artifacts Package: Generalization

Student<<entity>>

Professor<<entity>>

Schedule<<entity>>

CourseOffering<<entity>>

CourseOfferingList

1

Prerequisites

0..*Course

<<entity>> 0..*

1

instructor

0..1

0..*

0..*0..*

0..*

0..4

primaryCourses

0..*

0..2alternateCourses

0..*

1

Example: University Artifacts Package: Associations

IBillingSystem<<Interface>>

ICourseCatalogSystem<<Interface>>

Example: External System Interfaces Package

• Realizes one or more interfaces that define its behavior

Subsystem

Review: Subsystems and Interfaces

InterfaceRealization (Canonical form)

Realization (Elided form)Interface Name

Subsystem Name <<subsystem>>

Interface Name<<interface>>

Subsystem Name <<subsystem>>

Subsystems and Interfaces (continued)• Subsystems :

– Completely encapsulate behavior – Represent an independent capability with clear

interfaces (potential for reuse) – Model multiple implementation variants

InterfaceK

X()W()

<<Interface>>

SubsystemA<<subsystem>>

SubsystemB<<subsystem>>

ClassA1

W()

ClassA2

X()

ClassB1

W()Y()

ClassB2

X()

ClassB3

Z()

Encapsulation is the key!

Packages versus SubsystemsSubsystems

– Provide behavior– Completely

encapsulate their contents

– Are easily replaced

Subsystem A<<subsystem>>

Package B

ClassB1

ClassB2

Packages Don’t provide

behavior Don’t completely

encapsulate their contents

May not be easily replaced

Client Class

Subsystems raise the level of abstraction.

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)

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.

• 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

Candidate Subsystems

Subsystem A<<subsystem>>

Subsystem B<<subsystem>>

Subsystem C<<subsystem>>

Identifying Subsystems<<control>>

ClassA

X()W()

X()W()

<<Interface>>

“SupermanClass”

InterfaceK SubsystemA<<subsystem>>

ClassA1

X()

ClassA2

W()



Stable, well-defined interfaces are key to a stable, resilient architecture.

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.

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.

All other analysis classes map directly to design classes.

Analysis DesignExample: Design Subsystems and

InterfacesBillingSystem

//submit bill()

<<boundary>>

Billing System<<subsystem>>

IBillingSystem

submitBill(forTuition : Double, forStudent : Student)

CourseCatalogSystem

//get course offerings()

<<boundary>>

Course Catalog System <<subsystem>>

ICourseCatalogSystem

getCourseOfferings(forSemester : Semester, forStudent : Student) : CourseOfferingListinitialize()

Analysis Class Design Element

CourseCatalogSystem

BillingSystem

All other analysis classes map directly to design classes

CourseCatalogSystem Subsystem

BillingSystem Subsystem

Example: Analysis-Class-To-Design-Element Map

Interfaces start with an “I”

Modeling Convention: Subsystems and Interfaces

CourseCatalogSystem<<subsystem>>

ICourseCatalogSystem + initialize ()+ getCourseOfferings ()


+ initialize ()+ getCourseOfferings ()

ICourseCatalogSystem<<interface>>

+ getCourseOfferings () + initialize ()

Example: Subsystem Context: CourseCatalogSystem

Provided interfacedefined

ICourseCatalogSystem<<Interface>>

CloseRegistrationController

+ // is registration open?()+ // close registration()

<<control>>

0..1

+courseCatalog


+ initialize ()+ getCourseOfferings ()

+ getCourseOfferings ( for Semester: Semester ) + initialize ()

RegistrationController

+ getCurrentSchedule()+ deleteCurrentSchedule()+ submitSchedule()+ saveSchedule()+ getCourseOfferings()+ setSession()+ <<class>> new()+ getStudent()

<<control>>

CourseOfferingList

+ new()+ add()

1

Required interfacedefined

Example: Subsystem Context: Billing System

IBillingSystem

+ submitBill(forStudent : Student, forTuition : double)

<<Interface>>1

0..1

+ Biller 1

Student<<entity>>

CloseRegistrationController

+ // is registration open?()+ // close registration()

<<control>>

BillingSystem<<subsystem>>

+ submitBill(forStudent : Student, forTuition : double)



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

Software

Software

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

Software

Software

?

Reuse Opportunities Internal to System


ClassB

Y()Z()

ClassA

Y()Z()


ClassC

Y()Z()

ClassD

Y()Z()

ClassC

Y()Z()

ClassE

Y()Z()

Review: Typical Layering Approach

General functionality

Specific functionality 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.

ApplicationApplication

Business-SpecificBusiness-Specific

MiddlewareMiddleware

System SoftwareSystem Software

Goal is to reduce coupling and to ease maintenance effort.

Layering Considerations

• 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

Layer 1

Layer 2

Layer 3

Design Elements and the Architecture

Example: Architectural Layers

Middleware<<layer>>

Base Reuse

global


Business Services

<<layer>>

Necessary because the Application Layer must have access to the core distribution mechanisms provided with Java RMI.

Partitioning Considerations

• Coupling and cohesion• User organization• Competency and/or skill areas• System distribution• Secrecy• Variability

Try to avoid cyclic dependencies.

B

A Package A

Package B

Example: Partitioning

Registration

<<layer>>Application

Example: Application Layer

Security

GUI FrameworkSecure Interfaces


Business Services

<<layer>>

<<layer>>Application

<<layer>>Business Services

Example: Application Layer Context

University Artifacts

Registration

External System Interfaces

Example: Business Services Layer




ObjectStore Support


GUIFramework

SecureInterfaces

Security

<<subsystem>>SecurityManager


Middleware<<layer>>

Business Services

<<layer>>

Example: Business Services Layer Context

java.sqlcom.odi

<<layer>>Middleware





ObjectStore Support


GUIFramework

SecureInterfaces

Security

<<subsystem>>SecurityManager

com.odi

Database

(from com.odi)

Session

(from com.odi)

Transaction

(from com.odi)

Map

(from com.odi)

java.sql

ResultSet

(from com.odi)

Connection

(from com.odi)

Statement

(from com.odi)

DriverManager

(from com.odi)

Example: Middleware Layer

<<layer>>Middleware



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)• 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?

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: 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?

Architectural Analysis These slides are derived from IBM/Rational slides from courses on UML and object-oriented design and analysis. Copyright to the.

Documents

usecase realization

architecture design

use case modeling techniques

case driven use cases

software design techniques

software system

objectoriented design

design discipline