Software Architecture & Design · 28/01/2016 7 Presentation Layer Business Layer Data Management...
Transcript of Software Architecture & Design · 28/01/2016 7 Presentation Layer Business Layer Data Management...
Software Architecture & Design
6CCS3SAD
Dr Kevin Lano
Session 2:A Simple Process for Architecture Design
January 24th, 2020
At the end of this session you should be
able to:
– Design simple three-tiered architectures in a
systematic way.
Learning Outcomes
28/01/2016 3
Context
• Last week
– Basic architectural elements
– Simple architectures
– UML2 notation for architectures
• BUT: How do we get to an architecture?
– Today: A simple design process
– Based on:
Cheesman and Daniels: UML Components.
Addison Wesley 2001.
28/01/2016 4
Warning
• Architectural decisions mostly driven
by quality requirements
– Performance, security, reliability,
maintainability, evolvability, etc.
• Different requirements lead to different
architectures
• Today
– Focus on evolvability and maintainability
28/01/2016 5
3tier Architectures
28/01/2016 6
Presentation Layer
Business Layer
Data Management Layer
Desktop Client Web Client
Web Server
Application Server
Database Server
...
Refined View
28/01/2016 7
Presentation Layer
Business Layer
Data Management Layer
User Interface
Dialog Logic
Business Objects
Database Server
System Services
Development Process
28/01/2016 8
Requirements
Analysis
Specification Provisioning Assembly
Test
Deployment
Business
Requirements
Business
Concept Model
Component
Specs & Architecture
Components
Use Cases
This is a limited view. Refer to the book for a more precise perspective.
Requirements Analysis
28/01/2016 9
Requirements Analysis
Develop Business
Concept Model
Develop Use
Case Model
Domain Knowledge Requirements
Business Concept Model Use Cases
Business Concept Model
• Models all concepts in domain and their
relations
– Concepts as classes, relations as associations
• Rules
– Be generous
• Add stuff that may not make it into the application, can
always remove later!
– At this stage, don’t care about attributes and other
details
• Not architecturally relevant, will add later
28/01/2016
Business Concept Model (2)
28/01/2016 11
Hotel
ClerkHotel Chain
Customer Reservation Room
Room Type
Bill
Payment
Address 1
*
*
0..1
*1
1..*
1
1
*
11..*
*
contactedHotel
1..*
1
*
1
0..1
1
*
1
0..1
1
0..1
clerks
rooms
roomTyperoomType
Requirements Analysis
28/01/2016 12
Requirements Analysis
Develop Business
Concept Model
Develop Use
Case Model
Domain Knowledge Requirements
Business Concept Model Use Cases
Use Cases
• Use case
– A sequence of actions providing value to an
actor
• Scenario
– Sequence of steps within a use case
• Alternate user and system steps
28/01/2016 13
Use Cases (2)
28/01/2016 14
Reservation System
Make
Reservation
Cancel
Reservation
Update
Reservation
Guest
Use Cases (3)
• Each use case has a scenario, e.g.:
28/01/2016 15
Make
Reservation
1. Guest selects hotel, dates,
and room type
2. System provides availability
and price
3. Guest confirms choices
4. System makes reservation
Specification
28/01/2016 16
Requirements Analysis
Business Concept Model Use Cases
Specification
Component Identification
Component InteractionWe will come back to
this at the end of term
Component Specification
Recall: Refined View
28/01/2016 17
Presentation Layer
Business Layer
Data Management Layer
User Interface
Dialog Logic
Business Objects
Database Server
System Services (cf: Session bean)
(cf: Entity Bean)
System and Business Interfaces
28/01/2016 18
Business Layer
Business Objects
System Services
Business Component
Business Component
System Component
System Component
System Interfaces
Business Interfaces
Component Identification
28/01/2016 19
Component
Identification
Develop Business
Type Model
Identify System
Interfaces
Business Concept Model Use Cases
Business Type Model System Interfaces
Identify Business
Interfaces
Create Initial
Architecture
Business Interfaces Initial Architecture
Identify System Interfaces
• Provide operations required to
implement use cases
– Only system steps of use cases
– Only what is needed from dialog logic
• One interface per use case
– Later these may be rationalised if there are
common steps between different use cases
28/01/2016 20
Identify System Interfaces (2)
28/01/2016 21
Make
Reservation
Make
Reservation
<<interface>>
IMakeReservation
getHotelDetails()
getRoomInfo()
makeReservation()
1. Guest selects hotel, dates,
and room type
2. System provides availability
and price
3. Guest confirms choices
4. System makes reservation
BREAK
28/01/2016 22
Component Identification
28/01/2016 23
Component
Identification
Develop Business
Type Model
Identify System
Interfaces
Business Concept Model Use Cases
Business Type Model System Interfaces
Identify Business
Interfaces
Create Initial
Architecture
Business Interfaces Initial Architecture
Business Type Model
• Refinement of Business Concept Model
– Remove irrelevant concepts (not needed for
this specific application)
– Merge / Divide concepts
– Identify core types
– Remove aspects already implemented in an
existing system (eg., billing)
28/01/2016 24
Business Type Model (2)
28/01/2016 25
Hotel
ClerkHotel Chain
Customer Reservation Room
Room Type
Bill
Payment
Address 1
*
*
0..1
*1
1..*
1
1
*
11..*
*
contactedHotel
1..*
1
*
1
0..1
1
*
1
0..1
1
0..1
roomType
clerks
rooms
roomType
Identify Core/Dependent Types
• Core types
– Directly correspond to primary business
information
– Will form basis for component identification
• Dependent types
– Instances only make sense in connection to a
core type instance
• Category types
– Dependent types that classify other types
28/01/2016 26
Identify Core/Dependent Types (2)
• Core types
– Business identifier
– No mandatory associations (except to
category type)
– Mandatory means 1 multiplicity at the other
end of the association
28/01/2016 27
Identify Core/Dependent Types (3)
28/01/2016 28
Hotel
Customer Reservation Room
Room Type1
*
*
0..1
*1
1..*
1
1
*
1
*
1
1..*
Identify Core/Dependent Types (4)
28/01/2016 29
<<core>>
Hotel
<<core>>
Customer
<<type>>
Reservation
<<type>>
Room
<<category>>
Room Type1
*
*
0..1
*
1
1..*
1
1
*
1
*
1
1..*
Component Identification
28/01/2016 30
Component
Identification
Develop Business
Type Model
Identify System
Interfaces
Business Concept Model Use Cases
Business Type Model System Interfaces
Identify Business
Interfaces
Create Initial
Architecture
Business Interfaces Initial Architecture
Identify Business Interfaces (2)
• One interface per core type
– Spans a “region of responsibility” over
dependent types
• Associations between regions
– Try to limit number of these
– Where they remain: allocate responsibility to
one interface
• Use arrow notation to show on diagram
28/01/2016 31
Identify Business Interfaces
28/01/2016 32
<<core>>
Hotel
<<core>>
Customer
<<type>>
Reservation
<<type>>
Room
<<category>>
Room Type1
*
*
0..1
*
1
1..*
1
1
*
1
*
1
1..*
<<interface>>
IHotelMgt
<<interface>>
ICustomerMgt
Component Identification
28/01/2016 33
Component
Identification
Develop Business
Type Model
Identify System
Interfaces
Business Concept Model Use Cases
Business Type Model System Interfaces
Identify Business
Interfaces
Create Initial
Architecture
Business Interfaces Initial Architecture
Initial System Architecture
• Need to define components
• Starting assumption:
– One business component per business
interface
– One system component for all use cases
• Key question for decisions:
– Which functions belong together?
• Will need to evolve or be exchanged together, so
should be in one component
28/01/2016 34
Initial System Architecture (2)
28/01/2016 35
ReservationSystem
IMakeReservation
ICancelReservation
IUpdateReservation
BillingSystem
CustomerManager
HotelManager
IBilling ICustomerMgt IHotelMgt
Specification
28/01/2016 36
Requirements Analysis
Business Concept Model Use Cases
Specification
Component Identification
Component InteractionWe will come back to
this at the end of term
Component Specification
Component Interaction
• Need to find operations that should be
in business interfaces
– Analyse how system components need to
interact with business components
– For each system-interface operation, draw an
interaction diagram
• Identify business operations
• Identify parameters and return values for all
operations
28/01/2016 37
Component Interaction (2)
28/01/2016 38
ReservationSystem : IMakeReservation
: IHotelMgt : ICustomerMgt
makeReservation()
1. getCustomerMatching()2. makeReservation()
3. notifyCustomer()
<<interface>>
IMakeReservation
...
+makeReservation (res: ReservationDetails, cs: CustomerDetails) : String
<<interface>>
IHotelMgt
...
+makeReservation (res: ReservationDetails, csID: CustomerID) : String
<<interface>>
ICustomerMgt
...
+getCustomerMatching (cs : CustomerDetails) : CustomerID
+notifyCustomer (csID : CustomerID, message : String) : void
Summary
• A systematic approach to defining simple
architectures
– There’s more to it!
• We have not considered:
– Formal specification
– Implementation of components
• See the book for more details
– Limitations
• Mainly focused on evolvability
• Only for three-tier architectures
– BUT: A good starting point for any architecture design!
28/01/2016 39
Coming Up
• Compound components, simple and complex
architecture styles
• Implementation of components and
component architectures
– Beyond basic Java classes
– Complex forms of communication
– Domain-specific modelling issues
28/01/2016 40