Basics of Software Architecture and design with introduction to bare minimal UML and design patterns

1. Architecture and Design
Himanshu Airon

2. Agenda
 What is Architecture?
 Importance of Architecture in Software
 Software Architecture Principles
 Software Architecture tools
 Software Architecture patterns
 UML introduction
 RUP introduction

3. Definition
 The Software architecture of a program or computing
system is the Structure or structures of the system,
which comprise software elements, the externally visible
properties of those elements and the relationships
among them.

4. Why Architecture is important?
 Handling complexity
 Communication among stakeholders
 Early Design Decisions
 Software Architecture is a transferable, reusable model

5. Influences

6. Architecture Principles
 Single Responsibility Principle
 every class should have a single responsibility, and that responsibility should be entirely encapsulated
by the class
 Open – Closed Principle (OCP)
 Software Entities (Classes, Modules, Functions, etc.) should be open for extension but closed for
modifications.
 Liscov Substitution Principle (LSP)
 Functions that use pointers or references to base classes must be able to use(Substitute base class)
objects by derived classes without knowing it.
 Interface Segregation Principle (ISP)
 no client should be forced to depend on methods it does not use
 Dependency Inversion Principle
 A. High level modules should not depend on low level module. Both should depend on abstraction.
Both should depend on Abstraction.
 B. Abstraction should not depend on details.
 DRY (Don’t Repeat Yourself)
 Every piece of knowledge must have a single, unambiguous, authoritative representation within a
system.
 YAGNI - You ain't gonna need it
 Always implement things when you actually need them, never when you just foresee that you may
need them.
 KISS - Keep it simple, Stupid!
 Most systems work best if they are kept simple rather than made complex, therefore simplicity
should be a key goal in design and unnecessary complexity should be avoided.

7. Architecture Patterns
An Architecture style or Pattern is
 a description of the component and connector types
involved in the style
 the collection of rules that constrain and relate them
Example: MVC(Model-View-Controller), Layered, Multitier,
SOA(Service Oriented Architecture), Event Driven,
ETL(Extract-Transform-Load),EAI(Enterprise Application
Integration), ESB(Enterprise Service Bus), MFT(Managed
File Transfer), Data Warehouse, Analytical Reporting

8. Model-View-Controller
 Main goal:
facilitate and optimize the implementation of interactive systems,
particularly those that use multiple synchronized presentations of
shared information.
 Key idea:
separation between the data and its presentation, which is carried by
different objects.
 Controllers typically implement event-handling mechanisms that are
executed when corresponding events occur.
 Changes made to the model by the user via controllers are directly
propagated to corresponding views. The change propagation
mechanism can be implemented using the observer (design)
pattern.

9. Layered Pattern
 Context
You are working with a large, complex system and you want to
manage complexity by decomposition.
 Problem
How do you structure an application to support such operational
requirements as maintainability, scalability, extensibility,
robustness, and security?
 Solutions
Compose the solution into a set of layers. Each layer should be
cohesive and at Roughly the same level of abstraction. Each layer
should be loosely coupled to the layers underneath.

10. Layered Pattern cont…
 Layering consists of a hierarchy of layers, each providing
service to the layer above it and serving as client to the layer
below.
 Interactions among layers are defined by suitable communication
protocols.
 Interactions among non-adjacent layers must be kept to the
minimum possible.
 Layering is different from composition
 higher-layers do not encapsulate lower layers
 lower layers do not encapsulate higher layers (even though
there is an existence dependency)

11. Three Tier Architecture
 Context
You are building a business solution using layers to organize your
application.
 Problem
How do you organize your application to reuse business logic,
provide deployment flexibility and conserve valuable resource
connections?
 Solutions
 Create three layers: presentation, business logic and data
access.
 Locate all database-related code, including database clients
access and utility components, in the data access layer.
 Eliminate dependencies between business layer components and
data access components.
 Either eliminate the dependencies between the business layer
and the presentation layer or manage them using the Observer
pattern.

12. Three Tier Architecture
Presentation Tier
Business Tier
Integration Tier

13. Design Pattern
A design pattern systematically names, motivates, and explains a
general design that addresses a recurring design problem in object-
oriented systems. It describes the problem, the solution, when to
apply the solution, and its consequences. It also gives
implementation hints and examples. The solution is a general
arrangement of objects and classes that solve the problem. The
solution is customized and implemented to solve the problem in a
particular context.
Basic Design Patterns
 Creational Design Patterns (Factory, Abstract Factory, Builder,
Prototype, Singleton)
 Structural Design Pattern (Adapter, bridge, Composite, Decorator,
Façade, Flyweight, Proxy)
 Behavioral Design Pattern (Chain of Responsibility, Command,
Interpreter, Iterator, Mediator, Memento, Observer, State,
Strategy, Template, Visitor)

15. Modeling
 Modeling is a way of thinking about the problems using models
organized around the real world ideas.
 A modeling method comprises a language and also a
procedure for using the language to construct models.
 modeling is the only way to visualize your design and check it
against requirements before your crew starts to code.
 easier for developers, software architects and customers to
communicate on a common platform.
 we create a number of views of the system being described
• Each view is needed for a full understanding of the system
• Each view has information that is unique to that view.
• Each view has information that appears in other views

16. Motivations for UML
 We need a modeling language to:
o Help convey clear representations of user
requirements for clearer communication among
project stakeholders (concerned parties:
developers, customer, etc).
o help develop efficient, effective and correct
designs, particularly Object Oriented designs.
o give us the “big picture” view of the project.

18. UML 2 Diagrams
Structure diagrams define the static Behavior diagrams capture
architecture of a model. They are the varieties of interaction
used to model the 'things' that and instantaneous state
make up a model - the classes, within a model as it
objects, interfaces and physical 'executes' over time.
components.

19. UML Diagram purpose

20. Class Diagram
 Each class is represented by a rectangle divided into three sections:
o The first section is class name.
o The second section is attributes the class contain.
o The third section is operations of the class
 The lines connecting classes show the communication relationships
between the classes.
• Developers use Class diagrams to actually develop the classes.
• Analysts use Class diagrams to show the details of system.
• Architects looks at Class diagram to see the design of the system.
o If one class contains too much functionality, an architect can see
this in the Class diagram and split out it.

21. Class Diagram Notation

23. Class Diagram Sample
 A veterinary system. Animals served, such as dogs and birds,
are tracked along with their owners. Since dogs and birds are
"a kind of" animal, we use a Generalization relationship

24. Aggregation
 Aggregation is a kind of association
 “is part of” relation
o a book is part of a library catalog
o a library catalog has any number of books
Objective
o may make a diagram more readable
o maps to the same code as any other association

25. Composition
 Composition is a kind of aggregation with a well-defined
meaning!
 Example
class Rectangle {
private Point[ ] p = new Point[ 4 ];
//the elements of p are never given out
Rectangle( int x, int y, int height, int width ) {
p[ 0 ] = new Point( x, y );
…}
• Meaning: each part belongs to exactly one composite
o When the composite is destroyed, the part is destroyed
o Parts cannot be shared among composites

26. Dependency
 A depends on B
 Any kind of “uses” relation between classes that is not an
association or a generalization
Examples:
 A instantiates B (but does not keep the reference)
 A has operations that have objects of type B as parameters
Generally:
 Class A cannot be used without class B
 Dependency can also be used with packages

27. Interfaces
 Class Rectangle implements interface Shape
 Top: full representation
 Bottom: elided representation
 no operations of the interface can be shown
 The relation between class and interface is a realization
 Interfaces are a kind of class in UML

28. Abstract Classes
 Abstract classes and operations
 have names in italics
 this is an other way to show generalizations
 several arrows made into one

29. Package Diagram
 A grouping mechanism
 A package can contain any kind of
UML elements
Two uses:
 to hide part of a diagram
 to show the relationship between
large numbers of elements

30. Sequence Diagram Notation
Object Message
Lifeline of Object Object Activation
Actor

31. Sequence Diagram
 Shows the flow of functionality through a user story.
 Users can look at these diagrams to see the specifics of their
business processing.
 Analysts see the flow of processing in the Sequence
diagrams.
 Developers see objects the need to be developed and
operations for those objects.
 Quality assurance engineers can see the details of the
process and develop test cases based

32. Sequence Diagram Sample

33. Component Diagram
Component Dependency

34. Component Diagram
 Show you a physical view of your model
 The software components in your system, and relationships
between them.
 There are two types of components on the diagram:
 Executable component
 Code library
 Dependencies are drawn between the components (dahsed line).
 Component dependencies show the compile-time and run-time
dependencies between the components.

35. Component Diagram Sample
Register.exe
Billing.exe
Billing
System
People.dll
User
Course.dll
Course
Student Professor
Course Course
Offering

36. Deployment Diagram Notation
Component Association
Node

37. Deployment Diagram
 Deployment diagram shows the physical layout of the network and
where the various component will reside.

38. Rational Unified Process (RUP)

39. RUP 4+1 view
 Developed by Philippe Kruchten to describe the architectural
views needed to represent a software system.
 Founded on the notion that different users need different views
of the system
 Merges the technical aspects of a system with the requirements
that drive the system

40. RUP 4+1 view in Practice
 Logical View
 Models the translation of the system use cases into functional aspects
of the system
 Focus is on the how specific functionality is satisfied by architectural
abstractions (i.e. use case realizations)
 UML notation included most type of diagrams and elements(classes,
collaborations, state machines,…)
 This is where the meat of most modeling occurs
 Process View
 The process view is intended to show the concurrent execution
aspects of a system and the collaborations needed to support them.
 Usually expressed as tasks, threads, or active objects.
 In practice rarely used in general IT application development except in
special circumstances

41. RUP 4+1 view in Practice
 Implementation View
 Concerned with the representation of the system as modules, libraries,
sub-systems and other software components
 Shows the mapping of the design elements into their “deliverable” form
(ex. classes in a particular library)
 Usually uses UML component representation
 Deployment View
 Describes the deployment of the software elements of the system to the
hardware elements and the relationships between those hardware
elements.
 Very useful in distributed systems development.
 Uses the UML deployment notation.

42. RUP 4+1 view in Practice
 Use Case View
 The overarching view that drives the rest of the system in use case
driven development
 Models show the use cases and actors that define the requirements of
the system
 Usually uses use case diagrams and activity diagrams along with
supporting documentation that describes the use cases

43. Architectural Goals & Constraints
The architecture will be formed by considering:
 functional requirements, captured in the Use-Case Model, and
 non-functional requirements, quality attributes.
However these are constraints imposed by the environment in which
the software must operate that will shape the architecture :
 need to reuse existing assets
 imposition of various standards
 need for compatibility with existing systems

44. Requirements
Functional Requirements defines the capabilities and functions that
a System must be able to perform successfully. These are defined in
Use Cases or User Stories.
Non-functional Requirements are often called the Quality
Attributes or simply Qualities or Cross cutting concerns of a system.
These can be divided into two main categories:
 Execution Qualities e.g. security, reliability and usability which
are observable at the run time.(Dynamic)
 Evolution Qualities e.g. Testability, maintainability, extensibility,
scalability, which are in the static structure of the system.
The plan for implementing functional requirements is detailed in the
system design. The plan for implementing non-functional
requirements is detailed in the system architecture.