Unit 5 DOCUMENTING THE ARCHITECTURE By Prof. Dr. B. Chandramouli
Unit 5 Syllabus • • Good practices Documenting the Views using UML Merits and Demerits of using visual languages Need formal languages Architectural Description Languages ACME – Case studies. Special topics: – SOA and Web services – Cloud Computing – Adaptive structures
Why SWA documentation ? • To understand evaluate the design. This includes any of the application stakeholders, but most commonly other members of the design and development team. • To understand the design when we return to it after a period of time. • Others in the project team and development organization can learn from the architecture by digesting the thinking behind the design. ( KT) • We can do analysis on the design, perhaps to assess its likely performance, or to generate standard metrics like coupling and cohesion • To understand the design in order to maintain the developed system
Why SWA doc difficult ? • There’s no universally accepted architecture documentation standard. • An architecture can be complex, and documenting it in a comprehensible manner is time consuming • An architecture has many possible views. Documenting all the potentially useful views is time consuming and expensive. • An architecture design often evolves as the system is incrementally developed and more insights into the problem domain are gained. Keeping the architecture documents current is often an overlooked activity, especially with time and schedule pressures in a project.
Software Architecture and Design Documentation (Good Practices) • The Software Design Document (SDD) captures the design of a system • At minimum, create a document describing the software architecture of a system (or be able to produce the document from a tool) • You may package it into a separate document called Software Architecture Document 5
Software Architecture and Design Documentation (Good Practices) • You may also capture the detailed design (in the SDD document or in a modeling tool) – It should be clear from a detailed design how to produce an implementation, but… – A UML rendering of the implementation code is not a design model (it’s an implementation model with limited value) – The gap between the architecture and the implementation for smaller systems may be small, so you won’t need a detailed design – Or you may need detailed design only for some parts or aspects of the system – Or your subsystems may be as big as to require their own architecture document 6
Basic Rules for documentation 1. Documentation should be written from the point of view of the reader, not the writer. 2. Avoid repetition 3. Avoid unintentional ambiguity. 4. Organise document in a standard way 5. Record rationale ( logic and reasoning) 6. Keep it current 7. Review documentation for the current fitness of purpose
Documentation using UML • In general, SWA has 2 identities – Component and – Connectors • A component is a principal unit of runtime interaction or data storage • A connector is an interaction mechanism among components. • Examples – Pipe-and-filter view, filters are components, and pipes are the connectors. – In a shared-data view (repository / blackboard), the data repository and the assessors are the components, and the access mechanisms ( any network) are the connectors. – In a client-server view, the components are clients and servers, and the connectors are the protocol mechanisms by which they interact.
Why documentation of components important ? • Because components are the primary computational elements ( connectors only pass processed data) of a C&C view of a software architecture, they feature prominently in architectural documentation
What form the components ? • Object Oriented approach – Classes and Objects • Dataflow (pipe and filter) approach – Subsystems • Using the UML-RT Profile – UML profile is a collection of stereotypes, constraints, and tagged values @ Run Time that can be bundled to form a domain-specific language specialization.
Good practices of Documenting a View 7 parts 1. Primary presentation – this is usually graphical 2. Element catalog – details those elements depicted in the primary presentation 3. Context diagram – shows how the system relates to its environment 4. Variability guide – shows how to exercise any variability points 5. Architecture background – explains why this design. 6. Glossary of terms – contains a brief description of terms used in the view 7. Other information – contents of this section vary with the product and the organization
The Seven Parts of a Documented View
Visual Languages • In computing, a visual programming language (VPL) is any programming language that lets users create programs by manipulating program elements graphically rather than by specifying them textually. – E. g. Visual C++, Visual Basic ( MS Visual Studios), – Designer 2000 ( Oracle) • A VPL allows programming with visual expressions, spatial arrangements of text and graphic symbols, used as elements. For example, many VPLs (known as dataflow or diagrammatic programming) are based on the idea of "boxes and arrows", where – boxes or other screen objects are treated as entities ( data manipulation) and connected by arrows, lines or arcs which represent relations ( data communication)
Merits of Visual Programming Languages • Merits Fewer programming concepts Concreteness Explicit depiction of relationships Immediate visual feedback Eliminates an intermediate step in the process of creating a program • A different conceptual framework for the programming process(examples) • Parallel computation is a natural consequence of many visual programming paradigms • • •
Demerits of Visual Programming Languages • Deutsch Limit – The problem with visual programming is that you can't have more than 50 visual primitives on the screen at the same time. • Some situations in which text has superiority – documentation – naming to distinguish between elements that are of the same kind – expressing well-known and compact concepts that are inherently textual, e. g. algebraic formulas
Need formal Arch. languages • On a wider scale, formal methods provide abstract and non ambiguous model descriptions • Formal languages help build tools, – to prototype or – to test systems. • Model driven approaches integrate some degree of formalism. • Simple Box-and-line notations also describe SWA. But formal ADLs have proven very efficient to support both the design and verification.
Why do we use ADL ? • Necessity of using standardized architectural representation – ADLs bring standards for architecture description, just as what • UML do for design • Entity-relationship model do for database • Data flow diagram for Analysis – Using architectural styles for the structure • Pipe and filters • Client/Server – Using formal language • Components • Connectors – Makes the architecture universally understandable • Designers • Programmers • Stakeholders
Architectural Description Languages (ADL) • ADL is used for describing Formal specifications for modeling SWA concepts • ADL describes the structure and behavior of a software architecture • Structure: – Components, Connectors, Interfaces, Ports, Channels – Configurations, Constraints, Properties • Behavior: – How components and connectors behave – How they behave in integration – Constraints, Properties
Architecture Description Languages • The positives – ADLs represent a formal way of representing architecture – ADLs are intended to be both human and machine readable – ADLs support describing a system at a higher level than previously possible ( box n line) – ADLs permit analysis of architectures – completeness, consistency, ambiguity, and performance – ADLs can support automatic generation of design of software systems • The negatives – There is not universal agreement on what ADLs should represent, particularly as regards the behavior of the architecture – Representations currently in use are relatively difficult to parse and are not supported by commercial tools – Most ADL work today has been undertaken with academic rather than commercial goals in mind – Most ADLs tend to be very vertically optimized toward a particular kind of analysis
Some ADLs • Darwin & FSP – Imperial College London, J. Kramer & J. Magee • Koala – Philips Research • ACME – Carnegie-Mellon, D. Garlan • Rapide – Stanford, D. Luckham • x. Arch/x. ADL – University of California, Irvine
ACME • ACME was developed jointly by Monroe, Garlan (CMU) and Wile (USC) • ACME is a general purpose ADL originally designed to represent simple interchange language – ACME as a language is extremely simple (befitting its origin as an interchange language) • ACME has no native behavioral specification facility so only syntactic linguistic analysis is possible – there are currently efforts under consideration to define a behavioral semantics for ACME • ACME has no native generation capability • ACME has seen some native tool development, and there are indications of more, as well as use of other language tools via interchange
An ADL Example (in ACME) System simple_cs = { Component client = {Port send-request} Component server = {Port receive-request} Connector rpc = {Roles {caller, callee}} Attachments : {client. send-request to rpc. caller; server. receive-request to rpc. callee} }
rpc client send-request caller callee server receive-request
ACME : Qualities and Lacks • A common interchange language: Provide variety of tools belonging to several ADLs Easy to use : one format for all ADLs, programmers don’t have to master all ADL’s languages User-friendly interface • Very complete, lot of functions • Seven basics entities • components ( client, server) • connectors (rpc, send_req, rec_req) • Roles ( caller, callee) • Easy for the user, don’t need to learn ACME language
ACME : Qualities and Lacks (CONT. ) • ACME provides translation between 2 ADLS – don’t provide advanced tools for each ADL – you may turn to another tool if you want describe detailed architecture • Should limit the class of systems of ADLs for translations – often important and painful trade-offs have to be made to permit the success of translation • Try to develop a translator bi-directionality will complicate the program a lot – loss of a main functionality
Special Topic SOA and Web services
General • SOA all about data • Any engg appl Dam construction – Once constructed, changing difficult ( not possible) – Design is easy and less expensive – Construction difficult and expensive • Software Facebook / Whatsapp – Once constructed, changing easy ? ( must be possible) – Design is tough and expensive – Construction must be made easy and inexpensive
What are “Web Services” and SOA? • What is a service ? – A service is a software entity ( which is available in a public domain) that can be discovered and invoked by other software systems. • What is Web service ? – A Web service is a software system identified by a Uniform Resource Identifier (URI), whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML based messages conveyed by internet protocols • What is SOA ? – A service-oriented architecture (SOA) is an architectural pattern in computer software design in which application components provide services to other components via a communications protocol, typically over a network. The principles of service-orientation are independent of any vendor, product or technology.
Web Services Standardization Bodies • W 3 C: World Wide Web Consortium – the most notable web organization founded in 1994 by the inventor of the web – Web Architecture, Document formats, interaction, etc • OASIS: Organization of Structured Information Standards – Drives the development, convergence and adoption of e-business standards – Service register and publish, Security, Transaction, etc • WS-I: Web Services Interoperation Organization – Initiated by IBM, Microsoft and other vendors – Articulate/promote a common Web Services vision – Integrate specifications from various standards bodies
Web Services Basic Architecture • Web services are consistent with established Service-Oriented Architecture(SOA) principles. • Web Services Component – Service Description • Web services Roles – Service providers. – Service brokers – Service requestors. • Web Services Operations – Publish – Find – Interact
The Conceptual Web Service Stacks • Format: XML, Extensible Markup Language, to define structures of documents • Search and Find: UDDI Universal Discovery Description and Integration, for registries of Web services • Description: WSDL Web Services Description Language, to describe networked XML-based services • Messaging: SOAP • Simple Object Access Protocol, to define a uniform way of passing XML-encoded data. • Transport: Internet Protocol, HTTP, STMP, etc.
Operations and Message Flow
Pre-SOA Scenario Customer Data Back. End System Partner Credit Data Back. End System Customer Data
SOA-Enabled Scenario Partner Credit Data Back-End System Customer Data
Example: Purchase Service
Purchase Service Functions
Purchase Service Functions Service description Business Process Execution Language Enterprise Java Beans Deployed On J 2 EE (appl. Build) Communication protocol Query Lang EXtensible Stylesheet Language ( messaging)
Benefits of SOA • Flexible IT – Faster to Market – Changeable Business Processes • Meet current/future market conditions • Simplified Business Integration – Seamless integration with customers and partners • Visible Business Process – Mutable, Extensible, Reusable – IT Governance and Compliance • Align IT and Business Units • Enterprise Application Integration • Composite Application via Business Process Management
Special Topic Cloud computing
Cloud computing ? • Cloud computing is using the internet to access someone else's software running on someone else's hardware in someone else's data center.
Basic Cloud Definitions • A model of computation and data storage based on “pay as you go” access to “unlimited” remote data center capabilities • A cloud infrastructure provides a framework to manage scalable, reliable, on-demand access to applications • Cloud services provide the “invisible” backend to many of our mobile applications • High level of elasticity in consumption • Historical roots in today’s Internet apps • Search, email, social networks • File storage (Live Mesh, Mobile Me, Flicker, …) 45
NIST Cloud Definition “The National Institute of Standards and Technology (NIST) defines cloud computing as a "pay-per-use model for enabling available, convenient and ondemand network access to a shared pool of configurable computing resources (e. g. , networks, servers, storage, applications and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. " 46 April 2009
Architecture • Architecture consists of 3 tiers – Cloud Deployment Model – Cloud Service Model – Essential Characteristics of Cloud Computing 47
Architecture NIST Visual Model of Cloud Computing Definition 48
Essential Characteristics 1 • On-demand self-service. – A consumer can unilaterally provision computing capabilities such as server time and network storage as needed automatically, without requiring human interaction with a service provider. 49
Essential Characteristics 2 • Broad network access. – Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e. g. , mobile phones, laptops, and PDAs) as well as other traditional or cloudbased software services. 50
Essential Characteristics 3 • Resource pooling. – The provider’s computing resources are pooled to serve multiple consumers using a multitenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. 51
Essential Characteristics 4 • Rapid elasticity. – Capabilities can be rapidly and elastically provisioned - in some cases automatically - to quickly scale out; and rapidly released to quickly scale in. – To the consumer, the capabilities available for provisioning often appear to be unlimited and can be purchased in any quantity at any time. 52
Essential Characteristics 5 • Measured service. – Cloud systems automatically control and optimize resource usage by leveraging a metering capability at some level of abstraction appropriate to the type of service. – Resource usage can be monitored, controlled, and reported - providing transparency for both the provider and consumer of the service. 53
Cloud Service Models • Cloud Software as a Service (Saa. S) • Cloud Platform as a Service (Paa. S) • Cloud Infrastructure as a Service (Iaa. S) 54
What is Software as a Service? (Saa. S) • Saa. S is a software delivery methodology that provides licensed multi-tenant access to software and its functions remotely as a Web-based service. – Usually billed based on usage – Usually multi tenant environment – Highly scalable architecture
Software as a Service (Saa. S) • The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure. • The applications are accessible from various client devices through a thin client interface such as a web browser (e. g. , web-based email). • The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited userspecific application configuration settings. 56
Saa. S providers • • Google, Microsoft, Sales. Force, Yahoo
Saa. S Examples
Infrastructure as a Service (Iaa. S) • Iaa. S is the delivery of technology infrastructure as an on demand scalable service • Usually billed based on usage • Usually multi tenant virtualized environment • Can be coupled with Managed Services for OS and application support
Infrastructure as a Service (Iaa. S) • The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources. • Consumer is able to deploy and run arbitrary software, which can include operating systems and applications. • The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly limited control of select networking components (e. g. , host firewalls). 60
Iaa. S providers • • IBM Smart. Cloud Enterprise, Amazon Elastic Compute Cloud (EC 2), Rack. Space Hosting, Microsoft
Iaa. S Examples
Platform as a Service (Paa. S) • Paa. S provides all of the facilities required to support the complete life cycle of building and delivering web applications and services entirely from the Internet. • Typically applications must be developed with a particular platform in mind • Multi tenant environments • Highly scalable multi tier architecture
Platform as a Service (Paa. S) • The capability provided to the consumer is to deploy onto the cloud infrastructure consumer created or acquired applications created using programming languages and tools supported by the provider. • The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly application hosting environment configurations. 64
Paa. S providers • • • Google, Microsoft, TIBCO, VMware, Zoho
Paa. S Examples
Cloud Computing - Services Software as a Service - Saa. S Platform as a Service - Paa. S Infrastructure as a Service - Iaa. S
Cloud Deployment Models • • Public Cloud. Private Cloud. Community Cloud. Hybrid Cloud. 68
Cloud Security Forum Ref. Architecture 10/15/2013 Cloud Reference Architecture(s) IIT-RTC 69
Public Cloud • The cloud infrastructure is made available to the general public or a large industry group and is owned by an organization selling cloud services. 70
Private Cloud • The cloud infrastructure is operated solely for a single organization. It may be managed by the organization or a third party, and may exist on-premises or off-premises. 71
Community Cloud • The cloud infrastructure is shared by several organizations and supports a specific community that has shared concerns (e. g. , mission, security requirements, policy, or compliance considerations). It may be managed by the organizations or a third party and may exist on-premises or off-premises. • E. g…. IEEE standards on cybernetics ( community is all cyber crime detecting agencies) 72
Hybrid Cloud • The cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technology that enables data and application portability (e. g. , cloud bursting for load-balancing between clouds). 73
Private VS Public Cloud 74
CC - Opportunities and Challenges • It enables services to be used without any understanding of their infrastructure. • Cloud computing works using economies of scale • It potentially lowers the outlay expense for start up companies, as they would no longer need to buy their own software or servers. • Cost would be by on-demand pricing. • Vendors and Service providers claim costs by establishing an ongoing revenue stream. • Data and services are stored remotely but accessible from “anywhere”
CC - Advantages • Lower computer costs: – – You do not need a high-powered and high-priced computer to run cloud computing's web-based applications. Since applications run in the cloud, not on the desktop PC, your desktop PC does not need the processing power or hard disk space demanded by traditional desktop software. – When you are using web-based applications, your PC can be less expensive, with a smaller hard disk, less memory, more efficient processor. . . – In fact, your PC in this scenario does not even need a CD or DVD drive, as no software programs have to be loaded and no document files need to be saved. • Instant software updates: – – When the application is web-based, updates happen automatically – Whenever you access a web-based application, you get the latest version without needing to pay for or download an upgrade. – Improved document format compatibility. – You do not have to worry about the documents ( data) you create on your machine being compatible with other users' applications or OSes • e capacity: – – Cloud computing offers virtually limitless storage • Increased data reliability: – Unlike desktop computing, in which if a hard disk crashes and destroy all your valuable data, a computer crashing in the cloud should not affect the storage of your data.
Disadvantages • Need of Internet : - – Cloud computing is impossible if you cannot connect to the Internet. Since you use the Internet to connect to both your applications and documents, if you do not have an Internet connection you cannot access anything, even your own documents. – A dead Internet connection means no work and in areas where Internet connections are few or inherently unreliable, this could be a deal-breaker. – Requires a constant Internet connection • Can be slow: – – Even with a fast connection, web-based applications can sometimes be slower than accessing a similar software program on your desktop PC. • Disparate Protocols : - – Each cloud systems uses different protocols and different APIs – Standards yet to evolve.
The Future • Many of the activities loosely grouped together under cloud computing have already been happening and centralised computing activity is not a new phenomena • Grid Computing was the last research-led centralised approach. However there are concerns that the mainstream adoption of cloud computing could cause many problems for users • Many new open source systems appearing now may or may not be able to install and run on your local cluster
Special Topic Adaptive structures
Adaptive architecture • Adaptive architecture is a system which changes its structure, behavior or resources according to demand. • The adaptation made is usually to nonfunctional characteristics rather than functional ones.
Question Bank – 2 marks 1. 2. 3. 4. 5. Why documentation is necessary for software architecture ? Why documenting a software architecture is difficult ? List a few good practices in documenting a software architecture. List the basic rules for documenting a software architecture. What are the software architecture identities to be documented ? Give examples 6. Why documenting components important ? 7. What approaches form the components ? 8. What is UML – RT ? 9. List the 7 Good practices of Documenting a View 10. What are the merits and demerits of visual programming languages ?
Question Bank – 2 marks. . 11. What is the need formal architectural languages ? 12. What is ADL ? 13. Why do we use ADL ? 14. What are the merits and demerits of ADL ? 15. List some commercially available ADLs 16. What is referred to as ‘service ‘ ? 17. What is Web service ? 18. What is SOA ? 19. What is SOAP ? 20. What is WSDL ?
Question Bank – 2 marks … 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. List some benefits of SOA ? Define - cloud computing ? What are the 3 layers of cloud architecture ? List some characteristics of cloud computing List the cloud service models Define Saa. S ? Define Paa. S ? Define Iaa. S ? List the types of cloud deployment models Explain – public cloud Explain – private cloud Explain – hybrid cloud Explain – community cloud What are the advantages and disadvantages of cloud computing ? What is adaptive architecture ?
Question Bank – 16 marks 1. What are the good practices of documenting SWA ? 2. Write a note on the basic rules to be followed while writing SWA 3. Explain documenting views using UML. 4. Explain 7 parts Documentation of a View 5. Write a detailed note on ADL taking ACME as an example 6. Write detailed note on SOA 7. What is cloud architecture ? Discuss its merits and demerits 8. Draw and discuss the 3 layers of cloud architecture 9. Explain the 3 cloud service models. 10. Write a short note on adaptive architecture.
Скачать презентацию Unit 5 DOCUMENTING THE ARCHITECTURE By Prof Dr
27a8d29c7848f6387d5960c1017535b0.ppt