Interaction diagrams are at their best when they deal with one main design flow and not multiple variants that can happen B. Interaction diagrams are good at designing part or all of one use case's functionality across multiple objects. Please subscribe my channel TechvedasLearn for latest update.Lecture9 UML: Interaction, Collaboration and Sequence Diagram with exampleFriends, welcome to th.
- Interaction Diagram In Software Engineering Using
- System Interaction Diagram
- Interaction Overview Diagram
- Interaction Diagram In Software Engineering
CS616 – Software Engineering II |
Larman – Part5 – Elaboration: Iteration 3
Chapter 30 – Designing the Logical Architecture Patterns
·Objectives
oDesign a logical architecture in terms of layers and partitions with the Layers pattern
oIllustrate the logical architecture using UML package diagrams
oApply the Façade, Observer and Controller patterns
Software Architecture
·Software architecture deals with the large scale system
·Software architecture includes –
oorganization and major structure of the major elements of the system
osystem and subsystem behavior
ocollaborations
Identifying those functional and non-functional requirements that should have a significant impact on the system design
Resolution of requirements in the design of the software, the hardware and networking, etc.
- Logical Architecture – conceptual organization of system in layers, packages, major frameworks, classes, interfaces, subsystems
Three Levels:
- Architectural Patterns - related to large-scale and course-grained design
- Design Patterns – related to small and medium scale design of objects and frameworks
- Idioms – language oriented low-level design solutions
- Organize the large-scale logical structure of a system into discrete layers of distinct, related responsibilities, with a clean cohesive separation of concerns such that the 'lower' layers are low-level and general services, and the higher layers are more application specific.
- Collaboration and coupling is from higher to lower layers; lower to higher layer coupling is avoided
- Source code problems are rippling throughout the system – many parts of the system are highly coupled
- Application logic is intertwined with the user interface, and cannot be reused with a different interface, nor distributed to another processing mode
- Potentiall general technical services or business logic is intertwined with more application specific logic.
- There is a high coupling across different areas of concern. It is difficult to divide the work along clear boundaries for different developers
The purpose and number of layers varies across applications and application domains. Applied to information systems, typical layers look like this:
Partial layered architecture for NEXGEN application:
·Include diagram that illustrates noteworthy coupling events between layers and packages
·e.g. partial coupling between packages
- Use interaction diagrams to illustrate architecturally significant scenarios
- e.g. part of ProcessSale scenario that emphasizes connection points across layers
- Some packages are true subsystems with behavior and interfaces
- In UML, subsystem identified with a s stereotype:
- A public façade object defines the services for the subsystem
- Clients collaborate with the façade – not subsystem components
- e.g. POSRuleEngineFacade and PersistanceFacade
- Façade only exposes a small number of high level operations
- Façade does not do its own work – it mediates
- e.g. POSRuleEngineFacade is a wrapper
- Common for Domain Layer to expose to expose only one object to upper layer
- Technical services layer may expose multiple façades
System Operations and Layers
- SSDs illustrate system operations
- e.g. requests generated by an actor via Presentation Layer onto Application Layer
- When lower Application layer needs to communicate with Presentation Layer – done with Observer pattern
- UI objects in higher presentation layer implement an interface such as PropertyListener or AlarmListener and listen for events coming from lower layers
- e.g.
The Model-View Separation Principle
·What kind of visibility should other packages have to the Presentation Layer?
·How should non-window classes communicate with windows?
·Should be no direct coupling from other components to window objects
Model – Domain-Layer objects
View – presentation objects
·The Model-View Separation principle: model objects should have no direct knowledge of of view objects
·e.g. Register object should not directly send message to a GUI window object ProcessSaleFrame asking it to display something
·Windows can obtain information to display by sending messages to domain objects => polling or pull-from-above
·But polling is insufficient => push-from-below
Chapter 31 – Organizing the Design and Implementation Model Packages
·Objectives
oOrganize Packages to reduce impact of changes
Package Organization Guidelines
·GuideLine – Package Functionally Cohesive Vertical and Horizontal Slices
e.g. All NextGen Pricing package types are related to product pricing
·GuideLine – Package a Family of Interfaces
e.g. Java EJB package javax.ejb has 12 interfaces in separate packages
·GuideLine – Package by Work and by Cluster of Unstable Classes
e.g. packages are usually the basic unit of development work not classes
·GuideLine – Most Responsible are most stable
e.g. lowest-level classes are most stable
·GuideLine – Factor out Independent Types
Organize types that can be used independently or in different contexts into separate packages
·GuideLine – Use Factories to Reduce Dependency on Concrete Packages
Reduce dependency on concrete classes in other packages
·GuideLine – No Cycles in Packages
If a group of packages have cyclic dependency they should be treated as one larger package
Chapter 32 – Introduction to Architectural Analysis and SAD
·Create architectural factor tables
·Create technical memos that record architectural decisions
·Know basic principles for architectural design
·Know resources for learning architectural patterns
·UP records architectural factors in Supplementary Specification
Numark idj pro price. ·Architectural Decisions recorded in Software Architecture Document (SAD)
Architectural Analysis
- Identification and resolution of system's non-functional requirements within context of functional requirements
- Common Steps in Architectural Analysis
1.Identify and analyze the non-functional requirements that have an impact on the architecture
2.For requirements with a significant architectural impact, analyze alternatives and create solutions that resolve the impact
The Science: Identification and Analysis of Architectural Factors
·Architectural Factors
oStrongest architectural Factors – high level FURPS+ categories:
§Functionality
§Reliability
§Performance
§Supportability
§Implementation
§Interface
·Quality Scenarios
oDefine measurable or observable responses
oQuality scenarios are short statements of the form
e.g. When a bug report arrives from the NextGen beta test volunteer, reply with a phone call within 1 working day
Summary of themes in Architectural Analysis
- Architectural concerns are related to non-functional requirements and include an awareness of the business context
- Architectural concerns involve system-level, large-scale and broad problems whose resolution usually involves large-scale or fundamental design decisions
- Interdependencies and trade-offs
- Generation and and evaluation of alternative solutions
Architectural Analysis within UP
Six Views:
- SSDs illustrate system operations
- e.g. requests generated by an actor via Presentation Layer onto Application Layer
- When lower Application layer needs to communicate with Presentation Layer – done with Observer pattern
- UI objects in higher presentation layer implement an interface such as PropertyListener or AlarmListener and listen for events coming from lower layers
- e.g.
The Model-View Separation Principle
·What kind of visibility should other packages have to the Presentation Layer?
·How should non-window classes communicate with windows?
·Should be no direct coupling from other components to window objects
Model – Domain-Layer objects
View – presentation objects
·The Model-View Separation principle: model objects should have no direct knowledge of of view objects
·e.g. Register object should not directly send message to a GUI window object ProcessSaleFrame asking it to display something
·Windows can obtain information to display by sending messages to domain objects => polling or pull-from-above
·But polling is insufficient => push-from-below
Chapter 31 – Organizing the Design and Implementation Model Packages
·Objectives
oOrganize Packages to reduce impact of changes
Package Organization Guidelines
·GuideLine – Package Functionally Cohesive Vertical and Horizontal Slices
e.g. All NextGen Pricing package types are related to product pricing
·GuideLine – Package a Family of Interfaces
e.g. Java EJB package javax.ejb has 12 interfaces in separate packages
·GuideLine – Package by Work and by Cluster of Unstable Classes
e.g. packages are usually the basic unit of development work not classes
·GuideLine – Most Responsible are most stable
e.g. lowest-level classes are most stable
·GuideLine – Factor out Independent Types
Organize types that can be used independently or in different contexts into separate packages
·GuideLine – Use Factories to Reduce Dependency on Concrete Packages
Reduce dependency on concrete classes in other packages
·GuideLine – No Cycles in Packages
If a group of packages have cyclic dependency they should be treated as one larger package
Chapter 32 – Introduction to Architectural Analysis and SAD
·Create architectural factor tables
·Create technical memos that record architectural decisions
·Know basic principles for architectural design
·Know resources for learning architectural patterns
·UP records architectural factors in Supplementary Specification
Numark idj pro price. ·Architectural Decisions recorded in Software Architecture Document (SAD)
Architectural Analysis
- Identification and resolution of system's non-functional requirements within context of functional requirements
- Common Steps in Architectural Analysis
1.Identify and analyze the non-functional requirements that have an impact on the architecture
2.For requirements with a significant architectural impact, analyze alternatives and create solutions that resolve the impact
The Science: Identification and Analysis of Architectural Factors
·Architectural Factors
oStrongest architectural Factors – high level FURPS+ categories:
§Functionality
§Reliability
§Performance
§Supportability
§Implementation
§Interface
·Quality Scenarios
oDefine measurable or observable responses
oQuality scenarios are short statements of the form
e.g. When a bug report arrives from the NextGen beta test volunteer, reply with a phone call within 1 working day
Summary of themes in Architectural Analysis
- Architectural concerns are related to non-functional requirements and include an awareness of the business context
- Architectural concerns involve system-level, large-scale and broad problems whose resolution usually involves large-scale or fundamental design decisions
- Interdependencies and trade-offs
- Generation and and evaluation of alternative solutions
Architectural Analysis within UP
Six Views:
- Logical
Conceptual organization of the software in terms of most important layers, subsystems, packages, frameworks, classes, and interfaces
- Process
Process and threads wrt responsibilities, collaborations, and allocation of logical elements
- Deployment
Physical deployment of processes and components to processing nodes, and the physical network configuration between nodes
- Data
Overview of persistent data schema and their mappings to database objects
- Use Case
Summary of most architecturally significant use cases and their non-functional requirements
- Implementation
Actual source code and executables
·After the system is built – as a summary
·At the end of each iteration (e.g. elaboration I, II, III, …)
Interaction Diagram In Software Engineering Using
·Speculatively, during each iteration, as an aid to creative design
System Interaction Diagram
Sample Structure of SAD
·Architectural Representation
Summary of how the architecture will be described in this document
·Architectural Factors and Decisions
Reference to the Supplementary Specification
·Logical View
UML package diagrams and class diagrams of major elements
·Process View
UML class and interaction diagrams illustrating the processes and threads of the system
·Use-Case View
Interaction Overview Diagram
Brief summary of most architecturally significant use cases, UML interaction diagrams for some use cas realizations with commentary
Interaction Diagram In Software Engineering
·Deployment View
UML deployment diagrams showing the nodes and allocation of processes and components
