Presentation is loading. Please wait.

Presentation is loading. Please wait.

Architectural Modeling Software Architecture. Definition Every software system has an architecture either good or not good Capturing and recorded design.

Similar presentations


Presentation on theme: "Architectural Modeling Software Architecture. Definition Every software system has an architecture either good or not good Capturing and recorded design."— Presentation transcript:

1 Architectural Modeling Software Architecture

2 Definition Every software system has an architecture either good or not good Capturing and recorded design decisions is modeling Definition: – Architectural Model: An architectural model is an artifact that captures some or all of the design decisions that comprise a system’s architecture – Architectural modeling: Architectural modeling is the reflection and documentation of those design decisions Models help us to communicate, visualize, evaluate & evolve an architecture

3 Modeling Notations How we model is strongly influenced by the notations we choose: – An architectural modeling notation is a language or means of capturing design decisions Notations can be rich and ambiguous like natural language or can be semantically narrow and highly formal e.g. Rapid Broad variety of modeling notations are covered in this chapter

4 Architects and other stakeholders must make critical decisions: 1.What architectural decisions and concepts should be modeled, 2.At what level of detail, and 3.With how much rigor or formality Decisions should be based on costs and benefits Stakeholder-Driven Modeling

5 The benefits of creating and maintaining an architectural model must be balanced with the cost of doing so Choice of model and level of details has to be decided Most important or critical aspects of the system should be model in greatest detail with highest degree of formality/rigor Stakeholder-Driven Modeling

6

7 Basic activities behind stakeholder driven modeling: 1.Identify relevant aspects of the software to model 2.Roughly categorize them in terms of importance 3.Identify the goals of modeling for each aspect (communication, bugs finding, quality analysis and so on) 4.Select modeling notation that will model the selected aspects at appropriate levels of depth to achieve the modeling goals 5.Create the models 6.Use the models in a manner consistent with modeling goals Stakeholder-Driven Modeling

8 These steps are in chronological order but they can be executed in iterative manner From outside it can never be clear what are important aspects of the system, what are goals of modeling, whether these goals are achievable using available notations, technology, time and money. Estimations has to be reevaluated

9 1.Basic Architectural Concepts/elements 2.Elements of the Architectural Style 3.Static and Dynamic Aspects 4.Functional and Non-functional Aspects What do We Model?

10 1. Basic Architectural Concepts Some elements are common and important in every architecture when architectural design is considered. These elements are: – Components: Architectural building blocks that encapsulate a subset of system’s functionality and data – Connectors: Architectural building blocks that effect & regulate interactions among components – Interface: Points at which components and connectors interact with the outside world. i.e. with other components and connectors – Configuration: Combination of connectors and components. Represented via graphs where nodes – components & connectors and edges - interconnectivity – Rationale: Information that explains why particular architectural decisions were made & purpose of various elements

11 Basic architectural elements – Components – Connectors – Interfaces – Configurations – Rationale – reasoning behind decisions 11 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. Basic Architectural Concepts

12 These concepts forms starting point for architectural modeling Notations: box and arrows to represent components, connectors and interface Rationale has to be more expressive as it includes information. Rationale is usually model using natural language Basic modeling wont work for complex systems. These models must be extended and annotated with other concepts: what are nature of type of element? linking components and connectors means what etc… For small systems like word processor, components are static and less in numbers hence easy to describe each one For larger system like www, it is difficult to enumerate all the components. There are too many and constantly coming and going. For such system it is more reasonable to model only part of system or architectural style that governs the architecture Basic Architectural Concepts

13 2. Elements of the Architectural Style Arch. Style is collection of design decision in a particular domain, specific to a particular system Modeling arch. Style is very helpful in many ways It reduces confusion about what is and is not allowed in architecture Reduces drift and erosion Help to guide evolution of arch. Reusable from project to project Design decision in architectural style is more abstract or general than in architecture

14 Specific elements: style may prescribe that particular component,connector or interface be included or used in specific situation. Template or base model creation can support this in modeling Component connector and interface style: specific kinds of elements may be permitted, required or prohibited in the architecture. These elements can be of different semantics. We can model these elements 2. Elements of the Architectural Style

15 Interaction constraints: constraints may exist on interaction between components and connectors – Temporal constraint (calling component must call init() first before any other function) – Topological constraint (only client layer components can invoke server layer components) – Interaction protocol like https can be specified – Can be model using first order logic, temporal logic etc Behavioral constraints: constraints on behavior of elements can be model. FSM. Concurrency constraint: which elements support concurrency, have access to shared memory etc is specified in style which can be model. 2. Elements of the Architectural Style

16 3. Static and Dynamic Aspects Static aspects do not change. They do not involve system’s behavior while it is executing Dynamic aspects of the system involves system’s runtime behavior Static aspects are easier to model. They do not involve changes over time. Static aspects include components/connectors, topology, assignment of components or connectors to processing elements or host, n/w configuration etc..

17 Dynamic aspects of the system deal with how a system behaves or changes over time Dynamic aspects are harder to model Behavioral model, interaction model or data flow model contains dynamic aspect of the system. behavior, mode of interaction and data flow may change over time 3. Static and Dynamic Aspects

18 Static/dynamic distinction is not a clear line Some aspects like structure of system are stable, but under some conditions like system failure they may change. Models include both static and dynamic aspects of the system are employed for such cases where base topology allow limited set of changes that may occur during execution 3. Static and Dynamic Aspects

19 Static model captures properties of the system Static models can be in read only form Dynamic models refers to how the system(internal state) changes in as it executes Dynamic models changes itself Dynamic models has to be in machine readable and writable form 3. Static and Dynamic Aspects

20 4. Functional and Non-functional Aspects Functional aspects relate to WHAT system does Non-functional aspects relates to HOW system performs its function Example: – Functional: system prints medical record – Non-Functional: quickly and confidentially

21 Functional Aspects Functional aspects are more concrete and hence easier to model Can be modeled rigorously and formally Services provided by different components or connectors Behavior of the system Functional models can be static or dynamic in nature Most modeling notation focus on capturing functional aspects of the system

22 Modeling non functional aspect is not as perfect as functional aspects Many times Functional aspects are designed to achieve non functional properties of the system It is more informal Similar to rationale, non functional aspects are difficult to model They have to be more expressive and free from notations Natural language type notations are used for modeling non-functional aspects Non-Functional Aspects

23 Important Characteristics of Models Architectures are abstraction of the system Most important aspects of the system will be well defined by architectures Architectures are not complete implementation of system Notations used to capture architecture do not have to be completely unambiguous, accurate and precise Three key cancers of architectural model are: Ambiguity, precision and accuracy 23

24 Ambiguity – A model is ambiguous if it is open to more than one interpretation – Conflicting interpretation of model results in misunderstanding, errors, bugs – It is generally desirable to avoid ambiguity in the system – Incompleteness is a primary reason for ambiguity in models – Unspecified aspects results into different assumption of stakeholders Ambiguity

25 – Architectures are incomplete – Impossible to completely eliminate ambiguity – It will increase cost – Architects decides that architecture is ‘complete enough’ – Ambiguous aspects are better to be specified using rationale Ambiguity

26 Accuracy and Precision – A model is accurate if it is correct, conforms to fact, or deviates from correctness within acceptable limits – A model is precise if it is detailed, sharply exact or delimited

27 Accuracy vs. Precision 27 Inaccurate and imprecise: incoherent or contradictory assertions Accurate but imprecise: ambiguous or shallow assertions Inaccurate but precise: detailed assertions that are wrong Accurate and precise: detailed assertions that are correct Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

28 Complex Modeling Architectural models are complex artifacts Models captures all design decisions that are important to variety of stakeholders Different aspects of the same concept are captured simultaneously e.g. components behavior, interconnection and version history are captured separately about every component Too much information available to deal with Architects prefer to work with parts of architecture Various parts of the architecture will be modeled using different approaches like non functional aspects using natural languages, behavior using state charts, structure using component connector graph etc.

29 Views and Viewpoints Capturing everything in one model will make that model complex, confusing and too big Different aspects are captured in different models these subsets are called as views Views captures different concerns about the same concept These concerns or criteria about with which a view is taken viewpoint View: a view is a set of design decisions related by a common concern or set of concerns Viewpoint: a viewpoint defines the perspective from which a view is taken

30 Viewpoints Viewpoint is a filter to the information and view is what you see about the system through that filter Viewpoint is different angles with which system can be seen Viewpoints are means to capture different information of same concerns

31 Viewpoints Viewpoints that are commonly used: Logical Viewpoints – Capture the logical (often software) entities in a system and how they are interconnected. Physical Viewpoints – Capture the physical (often hardware) entities in a system and how they are interconnected. Deployment Viewpoints – Capture how logical entities are mapped onto physical entities. Concurrency Viewpoints – Capture how concurrency and threading will be managed in a system. Behavioral Viewpoints – Capture the expected behavior of (parts of) a system.

32 Multiple views can be taken from the same viewpoint for the same system with different details Example: different deployment views taken for same system where one view shows only top level components where another view shows top level components as well as subcomponents and additional internal structure Viewpoints

33 Importance of Views and Viewpoints They provide a way to limit presented information to a cognitively manageable subset of architecture They display related concepts simultaneously They can be tailored to the needs of specific stakeholders They can be used to display the same data at various levels of abstraction

34 Same or related information is presented in more than one view Whenever duplication is present, consistency issue comes forward How to say the views are consistent? Definition of consistency in terms of views: – Views are consistent if the design decision that they contain are compatible with each other Consistency Among Views

35 Inconsistency If there is no inconsistency that means views are consistent Inconsistency appears when two views assert design decisions that both at a time can not be true Inconsistency can arise in different ways Direct inconsistency: when two views assert opposite or contradictory design decisions – Example: system runs on two hosts, system runs on three hosts – This can be detected by automatic mechanism

36 Inconsistency Refinement inconsistency : when two views of the same system at different level of detail assert contradictory propositions Static aspects verses dynamic aspects : static view and dynamic view contradictory with each other. Somewhat harder to detect automatically Dynamic aspects : contradiction between two dynamic views. Extremely difficult to detect automatically Functional vs. non functional aspects : non functional property proposed by non functional vies is not achieved by functional view. Example: non functional view says system is robust but functionally system has only one server and no provision for system failure. Most difficult to detect

37 Evaluating Modeling Approaches Q. What are the dimensions that can be used for modeling techniques? Scope and purpose – What is intended to model, what is not! What techniques help you to model what does not. Basic elements – What are the basic elements that are modeled? How are they modeled? Style – To what extent does the approach help you model elements of the underlying architectural style? Is the technique bound to one particular style or family of styles? 37

38 Evaluating Modeling Approaches (cont’d) Static and dynamic aspects – What static and dynamic aspects of an architecture does the approach help you model? Dynamic modeling – To what extent does the approach support models that change as the system executes? Non-functional aspects – To what extent does the approach support (explicit) modeling of non-functional aspects of architecture? 38

39 Evaluating Modeling Approaches (cont’d) Ambiguity – How does the approach help you to avoid (or embrace) ambiguity? Accuracy – How does the approach help you to assess the correctness of models? Precision – At what level of detail can various aspects of the architecture be modeled? 39

40 Specific Modeling Techniques Architects have huge set of notations to model the different aspects of the system These techniques vary based on many things: what they can model, how precisely they can capture architectural semantics, how good their tool support is Which methods are used and for what purpose largely depends on stakeholders Many approaches are suitable in many domains but its not good to be attached to any one approach

41 Modeling Approaches Generic Technique – Natural language – PowerPoint-style modeling – UML, the Unified Modeling Language Early architecture description languages – Darwin – Rapide – Wright Domain- and style-specific languages – Koala – Weaves – AADL Extensible architecture description languages – Acme – ADML – xADL 41

42 Generic Techniques Generic techniques are often used to describe a software in whole or in part These are flexible but have few semantics Three types under generic techniques are: – Natural Language – Informal graphical PowerPoint-style modeling – UML, the Unified Modeling Language

43 Natural Language Natural languages are obvious way to document architectural design decisions They are ambiguous, non rigorous and informal in nature Can not be effectively processed by machines Can only be checked and inspected by humans Despite these drawbacks, for modeling some aspects of architecture, natural languages are the best modeling languages e.g. non- functional aspects Easily accessible to stakeholders Can be manipulated with common tools such as word processor Alternative is to use restricted form of it: – Avoid Similar terms of same meaning – Templates can be created with fill in the blanks places which makes it rigor in nature

44 Natural Language Evaluation 44 Scope and purpose u Capture design decisions with extensive vocabulary Basic elements u Any concepts required, no special support for any particular concept Style u Can be described by using more general language Static & Dynamic Aspects u Both aspect can be modeled Dynamic Models u Models must be changed by human No direct tie up to implemented/running system Non-Functional Aspects u Expressive vocabulary available

45 Ambiguity u Plain natural language tends to be ambiguous; statement templates and dictionaries help Accuracy u Manual reviews and inspection Precision u Can add text to describe any level of detail Viewpoints u Any viewpoint (but no specific support for any particular viewpoint) Viewpoint consistency u Manual reviews and inspection Natural Language Evaluation

46 Informal Graphical Power Point Style Tools like power point OmniGraffale provides ability to create decorative diagrams Supports easier way to create diagrams or charts Diagrams are easier way to express and understand Size limitation (one slide) helps to maintain abstract nature Informal graphical method similar to natural language as it also provide informal unconstrained way of expressing ideas Captures few semantics But lack in rigor required for more concrete models

47 Informal Graphical Model Example 47 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

48 Related Alternatives Some diagram editors (e.g., Microsoft Visio) can be extended with semantics through scripts and other additional programming – Generally ends up somewhere in between a custom notation-specific editor and a generic diagram editor – Limited by extensibility of the tool PowerPoint Design Editor (Goldman, Balzer) was an interesting project that attempted to integrate semantics into PowerPoint 48

49 49 Scope and purpose u Arbitrary diagrams consisting of symbols and text Basic elements u Geometric shapes, splines, clip-art, text segments Style u In general, no support to a specific style Static & Dynamic Aspects u Any aspect can be modeled, but no semantics behind models Dynamic Models u Rare, although APIs to manipulate graphics exist Non-Functional Aspects u With natural language annotations Informal Graphical Evaluation

50 Ambiguity u Can be reduced through use of rigorous symbolic vocabulary/dictionaries Accuracy u Manual reviews and inspection Precision u Up to modeler; generally canvas is limited in size (e.g., one ‘slide’) Viewpoints u Any viewpoint (but no specific support for any particular viewpoint) Viewpoint consistency u Manual reviews and inspection Informal Graphical Evaluation

51 Unified Modeling Language Designed by Booch, Rambaugh and jacobson Most popular notation for writing down software designs UML is a very big language to understand It captures all details in different views Its viewpoint remains focused on design only It is biased towards object oriented languages UML diagram alone can not carry many details Natural language support is taken

52 UML Evaluation 52 Scope and purpose u Diverse array of design decisions in 13 viewpoints Basic elements u Multitude – states, classes, objects, composite nodes… Style u Through (OCL) constraints OCL-object constraint language Static & Dynamic Aspects u Some static diagrams (class, package), some dynamic (state, activity) Dynamic Models u Rare; depends on the environment Non-Functional Aspects u No direct support; natural-language annotations

53 Ambiguity u Many symbols are interpreted differently depending on context; profiles reduce ambiguity Accuracy u Well-formedness checks, automatic constraint checking, ersatz tool methods, manual Precision u Up to modeler; wide flexibility Viewpoints u Each diagram type represents a viewpoint; more can be added through overloading/profiles Viewpoint consistency u Constraint checking, ersatz tool methods, manual UML Evaluation

54 Early Architecture Description Language Research done in 1990’s decade how to best capture software architecture and the result was ADL Notations were developed specifically for architectural modeling Debate was which notations comes under ADL for capturing architectural design decisions Any language which is able to capture principal design decisions comes under ADL including UML – Darwin – Rapide – Wright

55 Languages under ADL Darwin General purpose ADL Specify structure of system, composed of components communicating through interface Graphical visualization is associated which depicts Darwin configuration in more accessible but less precise way Rapide: Rapid is ADL designed to specify dynamic aspects of the system It is composed of components that communicate using events Where events are simply result of activity Darwin: Checks components interaction


Download ppt "Architectural Modeling Software Architecture. Definition Every software system has an architecture either good or not good Capturing and recorded design."

Similar presentations


Ads by Google