Architecture and design

  • 189 views
Uploaded on

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

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

More in: Design
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
189
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
14
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • AnOrderDetailcan be queried about itsItem, but not the other way around. The arrow also lets you know who "owns" the association's implementation; in this case,OrderDetailhas anItem.Multiplicities are single numbers or ranges of numbers. In our example, there can be only oneCustomerfor eachOrder, but aCustomercan have any number ofOrders.

Transcript

  • 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 aint 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 PatternsAn 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 themExample: MVC(Model-View-Controller), Layered, Multitier,SOA(Service Oriented Architecture), Event Driven,ETL(Extract-Transform-Load),EAI(Enterprise ApplicationIntegration), ESB(Enterprise Service Bus), MFT(ManagedFile 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)
  • 14. 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
  • 15. 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.
  • 16. UML 2 DiagramsStructure diagrams define the static Behavior diagrams capturearchitecture of a model. They are the varieties of interactionused to model the things that and instantaneous statemake up a model - the classes, within a model as itobjects, interfaces and physical executes over time.components.
  • 17. UML Diagram purpose
  • 18. 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.
  • 19. Class Diagram Notation
  • 20. 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
  • 21. 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
  • 22. 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
  • 23. Dependency A depends on B Any kind of “uses” relation between classes that is not an association or a generalizationExamples: A instantiates B (but does not keep the reference) A has operations that have objects of type B as parametersGenerally: Class A cannot be used without class B Dependency can also be used with packages
  • 24. 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
  • 25. Abstract Classes Abstract classes and operations  have names in italics  this is an other way to show generalizations  several arrows made into one
  • 26. 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
  • 27. Sequence Diagram Notation Object Message Lifeline of Object Object Activation Actor
  • 28. 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
  • 29. Sequence Diagram Sample
  • 30. Component Diagram Component Dependency
  • 31. 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.
  • 32. Component Diagram Sample Register.exe Billing.exe Billing System People.dll User Course.dll Course Student Professor Course Course Offering
  • 33. Deployment Diagram Notation Component Association Node
  • 34. Deployment Diagram Deployment diagram shows the physical layout of the network and where the various component will reside.
  • 35. Rational Unified Process (RUP)
  • 36. 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
  • 37. 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
  • 38. 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.
  • 39. 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
  • 40. 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
  • 41. RequirementsFunctional Requirements defines the capabilities and functions thata System must be able to perform successfully. These are defined inUse Cases or User Stories.Non-functional Requirements are often called the QualityAttributes 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 thesystem design. The plan for implementing non-functionalrequirements is detailed in the system architecture.