Software Design and Architecture PDF

This document is for private circulation only, For T. Y. Computer 2024-25 CCEW students. Subject: Software Design and Architecture PLEASE refer TO ALL REFERENCES plus Study Material CIRCULATED. Feel free to use additional web sites/searches for understanding if required.  ACKNOWLE...

This document is for private circulation only, For T. Y. Computer 2024-25 CCEW students. Subject: Software Design and Architecture PLEASE refer TO ALL REFERENCES plus Study Material CIRCULATED. Feel free to use additional web sites/searches for understanding if required.  ACKNOWLEDGEMENT This presentation contains pictures, contents taken from multiple sources, authors and sites. We would like to appreciate and thank the authors, artists and do not claim any of following work to be ours, but it has been compiled here to use for academic purpose only.  Unit 2: Scope of This Document Importance of modeling, Object-oriented modeling Introduction to UML Conceptual model of UML - UML building blocks: Things, Relationships, Diagrams - Common mechanisms in UML - Extensibility mechanisms: - Stereotypes, Tagged values, Constraints Modeling a System’s architecture: 4+1 view model of architecture Ref: Grady Booch, James Rumbaugh, Ivar Jacobson, 'The Unified Modeling Language User Guide', Pearson Education, (2nd edition)(2008). Chapters: 1. Why we model 2. Introducing the UML  Importance of Modeling and Introduction to Unified Modeling Language What Is a Model?  Simplification of reality  Blueprints of a system blueprint (model) building building Visual Models  Different models for different aspects  Structural – Organization of the system  Behavioral – Dynamics of the system Why Do We Model?  Tobetter understand the system we are developing  Visualize, Specify, Construct, Document  Simplification and reuse  Large and Complex Systems!!  To Provide Template for building system Model Visually to…  Show how system elements fit together  Keep design and implementation consistent  Hide or expose details as appropriate  Manage risks of the mistakes  Four Principles of Modeling 1) The choice of what models to create has a profound influence on how a problem is attacked and how a solution is shaped. 2) Every model may be expressed at different levels of precision. 3) The best models are connected to reality. 4) No single model is sufficient. Every nontrivial system is best approached through a small set of nearly independent models. Four Principles of Modeling Four Principles of Modeling Four Principles of Modeling Four Principles of Modeling Four Principles of Modeling Unified Modeling Language (UML)  Object-oriented modeling language  Unificationof - Design and Construction oriented approach by Grady Booch - OMT by Rumbaugh - OOSE by Jacobson UML Features  Precise Syntax and Semantics  Promotes unambiguous communication  Process independent  Implementation language independent  A CONCEPTUAL MODEL OF UML  UML building blocks  Rules to connect the building blocks  Common mechanisms of UML  BUILDING BLOCKS OF UML The building blocks of UML can be defined as: 1) Things - Structural, Behavioral, Grouping, Annotational 2) Relationships 3) Diagrams STRUCTURAL THINGS Static part of the model. They represent physical and conceptual elements. Class: Class represents set of objects having similar responsibilities. Interface: Interface defines a set of operations which specify the responsibility of a class. Collaboration: Collaboration defines interaction between elements. Use case: Use case represents a set of actions performed by a system for a specific goal. Component: Component describes physical part of a system. Node: A node can be defined as a physical element that exists at run time. STRUCTURAL THINGS  Class Notation The top section is used to name the class. The second one is used to show the attributes of the class. The third section is used to describe the operations performed by the class. The fourth section is optional to show any additional components. BEHAVIORAL THING Dynamic parts of UML models. Interaction: Interaction is defined as a behavior that consists of a group of messages exchanged among elements to accomplish a specific task. State machine: State machine is useful when the state of an object in its life cycle is important. It defines the sequence of states an object goes through in response to events. Events are external factors responsible for state change. Grouping Things Organizational parts of UML models. These are the boxes into which a model can be decomposed. In all, there is one primary kind of grouping thing, namely, packages. A package is a general-purpose mechanism for organizing elements into groups. Structural things, behavioral things, and even other grouping things may be placed in a package. Unlike components (which exist at run time), a package is purely conceptual (meaning that it exists only at development time) Annotational Things These are the comments you may apply to describe, illuminate, and remark about any element in a model. Example: A note is simply a symbol for rendering constraints and comments attached to an element or a collection of elements. UML Relationships  Dependency  Association  Generalization  Realization UML Relationships It shows how the elements are associated with each other and this association describes the functionality of an application. Relationships depict a connection between several things, such as structural, behavioral, or grouping things in the unified modeling language. There are four kinds of relationships available. dependency, association, generalization, and realization. Dependency Dependency is a relationship between two things in which change in one element also affects the other. Association Association is basically a set of links that connects the elements of a UML model. It also describes how many objects are taking part in that relationship. Association is used to represent the relationship between two elements of a system. Generalization Generalization can be defined as a relationship which connects a specialized element with a generalized element. It basically describes the inheritance relationship in the world of objects. Generalization is used to describe parent-child relationship of two elements of a system. Realization Realization can be defined as a relationship in which two elements are connected. One element describes some responsibility, which is not implemented and the other one implements them. This relationship exists in case of interfaces. In UML modeling, the realization is a relationship between two objects, where the client (one model element) implements the responsibility specified by the supplier (another model element). The realization relationship can be employed in class diagrams and components diagrams. It is mostly found in the interfaces. Visual Modeling with UML Use-Case Class Diagrams Diagrams Sequence Diagrams Object Diagrams Models Collaboration Diagrams Component Diagrams Statechart Diagrams Deployment Activity Diagrams Diagrams Common Mechanisms in UML 1. Specifications 2. Adornments 3. Common divisions 4. Extensibility mechanisms Specifications In UML, behind each graphical notation, there is a textual statement denoting the syntax and semantics. The specifications provide a semantic backplane that contains all the parts of a system and the relationship among the different paths. Specify -give details Each and everything can be specified say class,use case etc. Adornments Each element in UML has a unique graphical notation. there are notations to represent the important aspects of an element like name, scope, visibility, etc. Note is a graphical representation for comment and constraint.  Common Divisions Common divisions are used in order to distinguish between two things that might appear to be quite similar, or closely related to one another. Object-oriented systems can be divided in many ways. The two common ways of division are − Division of classes and objects − A class is an abstraction of a group of similar objects. An object is the concrete instance that has actual existence in the system. Division of Interface and Implementation − An interface defines the rules for interaction. Implementation is the concrete realization of the rules defined in the interface. Extensibility mechanisms Stereotypes Tagged Values Constraints Stereotypes  A stereotype is an extension of the vocabulary of the UML.  Defines a new model element that’s specific to the problem you’re trying to solve.  Introducenew things that speak the language of your domain and look like primitive building blocks.  Stereotype Example Student Student With guillemets Iconified form With icon Stereotypes are rendered as text inside guillemets(>) or we can create new icons for stereotypes. Tagged Values  A tagged value is an extension of the properties of a model element.  Allows you to create new information within the specification of that element. Tagged Value Example Math {version = 3.2 Author = ssd} add( ) multiply( ) Constraints  A constraintis an extension of the semantics of a model element.  A constraint specifies conditions that must be held true. Constraints Example ATM_Withdrawal queue customer : id amount : Money {amount is multiple of $20} add( ) {ordered} remove( ) Applying the UML Information GUI Intensive Systems Systems Distributed Real-time Web-based Systems Systems  Where Can the UML Be Used? Enterprise information systems Banking and financial services Telecommunications Transportation Defense/aerospace Retail Medical electronics Scientific Distributed Web-based services  INTRODUCTION TO UML DIAGRAM.  UML stands for U nified M odelling L anguage. UML is a standard language for specifying, visualizing, constructing, and documenting a system in which software represents the most significant part. UML is different from the other common programming languages like C++, Java, COBOL etc.  UML is a pictorial language used to make software blue prints. UML can serve as a central notation for software development process. Using UML helps project teams communicate, explore potential designs, and validate the architectural designs of software.  UML diagrams are made using notation of things and relationships. 4+1 View Model of Architecture  Use Case View The use case view of a system encompasses the use cases that describe the behavior of the system as seen by its end users, analysts, and testers. This view doesn't really specify the organization of a software system. Rather, it exists to specify the forces that shape the system's architecture. With the UML, the static aspects of this view are captured in use case diagrams; the dynamic aspects of this view are captured in interaction diagrams, statechart diagrams, and activity diagrams.  Design View  The design view of a system encompasses the classes, interfaces, and collaborations that form the vocabulary of the problem and its solution.  This view primarily supports the functional requirements of the system, meaning the services that the system should provide to its end users.  With the UML, the static aspects of this view are captured in class diagrams and object diagrams; the dynamic aspects of this view are captured in interaction diagrams, state chart diagrams, and activity diagrams.  Process View / Interaction View The process view of a system encompasses the threads and processes that form the system's concurrency and synchronization mechanisms. This view primarily addresses the performance, scalability, and throughput of the system.  With the UML, the static and dynamic aspects of this view are captured in the same kinds of diagrams as for the design view, but with a focus on the active classes that represent these threads and processes.  Implementation View  The implementation view of a system encompasses the components and files that are used to assemble and release the physical system. This view primarily addresses the configuration management of the system's releases, made up of somewhat independent components and files that can be assembled in various ways to produce a running system.  With the UML, the static aspects of this view are captured in component diagrams; the dynamic aspects of this view are captured in interaction diagrams, state chart diagrams, and activity diagrams.  Deployment View  The deployment view of a system encompasses the nodes that form the system's hardware topology on which the system executes. This view primarily addresses the distribution, delivery, and installation of the parts that make up the physical system.  With the UML, the static aspects of this view are captured in deployment diagrams; the dynamic aspects of this view are captured in interaction diagrams, state chart diagrams, and activity diagrams.  ACKNOWLEDGEMENT This presentation contains pictures, contents taken from multiple sources, authors and sites. We would like to appreciate and thank the authors, artists and do not claim any of above work to be ours, but it has been compiled here to use for academic purpose only.