1. Software Architecture & Design
6CCS3SAD / 7CCSMDAS
Dr Kevin Lano

2. Session 2: A Simple Process for Architecture Design
January 21st, 2019
global rates of flow
communication patterns
execution control structure
scalability
paths of system evolution
capacity
throughput
consistency
component compatibility

3. Learning Outcomes At the end of this session you should be able to:
Design simple three-tiered architectures in a systematic way.
28/01/2016

4. Context Last week BUT: How do we get to an architecture?
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

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

6. 3tier Architectures Presentation Layer Swing Client ... Web Client
Web Server
Business Layer
Application Server
Data Management Layer
Database Server
28/01/2016

7. Refined View Presentation Layer User Interface Dialog Logic
Business Layer
System Services
Business Objects
Data Management Layer
Database Server
28/01/2016

8. Development Process Requirements Analysis Specification Provisioning
Business
Requirements
Requirements
Analysis
Use Cases
Business
Concept Model
Specification
Provisioning
Assembly
Component
Specs & Architecture
Components
Test
Deployment
This is a limited view. Refer to the book for a more precise perspective.
28/01/2016

9. Requirements Analysis
Domain Knowledge
Requirements
Requirements Analysis
Develop Business
Concept Model
Develop Use
Case Model
Business Concept Model
Use Cases
28/01/2016

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

11. Business Concept Model (2)1
Hotel Chain
Clerk
1..*
1..* 1
contactedHotel
Hotel 1 * 1 * *
1..* 1 *
Customer
Reservation
Room *
0..1 1 1 * * 1
0..1
Room Type
Address 1
0..1
Bill 1
0..1
Payment
28/01/2016

12. Requirements Analysis
Domain Knowledge
Requirements
Requirements Analysis
Develop Business
Concept Model
Develop Use
Case Model
Business Concept Model
Use Cases
28/01/2016

13. Use Cases Use case Scenario
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

14. Use Cases (2) Reservation System Make Reservation Cancel Update Guest
NOTE: These are only a selection of use cases
28/01/2016

15. Use Cases (3) Each use case has a scenario, e.g.: Make Reservation
Guest selects hotel, dates, and room type
System provides availability and price
System makes reservation
28/01/2016

16. Specification Requirements Analysis Specification
Business Concept Model
Use Cases
Specification
Component Identification
Component Interaction
We will come back to
this at the end of term
Component Specification
28/01/2016

17. Recall: Refined View (cf: Session bean) (cf: Entity Bean)
Presentation Layer
User Interface
Dialog Logic
Business Layer
(cf: Session bean)
System Services
Business Objects
(cf: Entity Bean)
Data Management Layer
Database Server
28/01/2016

18. System and Business Interfaces
System Interfaces
Business Layer
System Services
System
Component
System
Component
Business Objects
System interfaces: Support Use Case Steps
Business Interfaces: Support business logic
Business
Component
Business
Component
Business Interfaces
28/01/2016

19. Component Identification
Business Concept Model
Use Cases
Component
Identification
Develop Business
Type Model
Identify Business
Interfaces
Identify System
Interfaces
Create Initial
Architecture
Business Type Model
Business Interfaces
Initial Architecture
System Interfaces
28/01/2016

20. Identify System Interfaces
Provide operations required to implement use cases
Only system steps of use cases
Only what is needed from dialog logic (this may cache information!)
One interface per use case
Later these may be rationalised if there are common steps between different use cases
28/01/2016

21. Identify System Interfaces (2)
Make
Reservation
Make
Reservation
<<interface>>
IMakeReservation
getHotelDetails()
getRoomInfo()
makeReservation()
Guest selects hotel, dates, and room type
System provides availability and price
System makes reservation
28/01/2016

22. Break
28/01/2016

23. Component Identification
Business Concept Model
Use Cases
Component
Identification
Develop Business
Type Model
Identify Business
Interfaces
Identify System
Interfaces
Create Initial
Architecture
Business Type Model
Business Interfaces
Initial Architecture
System Interfaces
28/01/2016

24. Business Type Model Refinement of Business Concept Model
Remove irrelevant concepts
Merge / Divide concepts
Identify core types
28/01/2016

25. Business Type Model (2) Hotel Chain Clerk Hotel Customer Reservation1
Hotel Chain
Clerk
1..*
1..* 1
contactedHotel
Hotel 1 * 1 * *
1..* 1 *
Customer
Reservation
Room *
0..1 1 1 * * 1
0..1
Room Type
There are different reasons for removing concepts:
Irrelevance to the implementation (hotel chain, clerk, contactedHotel) – we will never store data for these concepts in the application
Merging with other concepts (address is merged into customer)
Handled by legacy components (bill, payment)
Address 1
0..1
Bill 1
0..1
Payment
28/01/2016

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

27. Identify Core/Dependent Types (2)
Core types
Business identifier
No mandatory associations (except to category type)
28/01/2016

28. Identify Core/Dependent Types (3)1 1
Hotel 1 *
1..* 1 *
Customer
Reservation
Room *
0..1 * * 1
Room Type 1
1..*
28/01/2016

29. Identify Core/Dependent Types (4)
Hotel
Customer
<<type>>
Reservation
Room
<<category>>
Room Type 1 *
0..1
1..*
28/01/2016

30. Component Identification
Business Concept Model
Use Cases
Component
Identification
Develop Business
Type Model
Identify Business
Interfaces
Identify System
Interfaces
Create Initial
Architecture
Business Type Model
Business Interfaces
Initial Architecture
System Interfaces
28/01/2016

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

32. Identify Business Interfaces
<<core>>
Hotel
Customer
<<type>>
Reservation
Room
<<category>>
Room Type 1 *
0..1
1..*
<<interface>>
IHotelMgt
<<interface>>
ICustomerMgt
28/01/2016

33. Component Identification
Business Concept Model
Use Cases
Component
Identification
Develop Business
Type Model
Identify Business
Interfaces
Identify System
Interfaces
Create Initial
Architecture
Business Type Model
Business Interfaces
Initial Architecture
System Interfaces
28/01/2016

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

35. Initial System Architecture (2)
IMakeReservation
ICancelReservation
IUpdateReservation
Reservation
System
IBilling
ICustomerMgt
IHotelMgt
Billing
System
Customer
Manager
Hotel
Manager
28/01/2016

36. Specification Requirements Analysis Specification
Business Concept Model
Use Cases
Specification
Component Identification
Component Interaction
We will come back to
this at the end of term
Component Specification
28/01/2016

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

38. Component Interaction (2)
makeReservation()
/IMakeReservation : ReservationSystem
2. makeReservation()
1. getCustomerMatching()
3. notifyCustomer()
/IHotelMgt
/ICustomerMgt
<<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
28/01/2016

39. 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
Severe limitations
Mainly focused on evolvability
Only for three-tier architectures
Not sure how well it scales up
BUT: A good starting point for any architecture design!
28/01/2016

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