tailieunhanh - Lecture Software engineering: Lecture 4 - Ivan Marsic

Lecture 4: Software architecture. The main contents of this chapter include all of the following: Problem structure vs. solution structure, software architecture definition, architectural decisions & key concerns, architectural styles, documenting architecture: views. | Ivan Marsic Rutgers University LECTURE 4: Software Architecture Topics Problem Structure vs. Solution Structure Software Architecture Definition Architectural Decisions & Key Concerns Architectural Styles Documenting Architecture: Views Hierarchical Organization of Software Software is not one long list of program statements but it has structure Taxonomy of structural parts (abstraction hierarchy), but not representation of relationships between the parts and does not specify the function of each part System or product Subsystems/Modules Packages Classes/Objects Methods highest abstraction level lowest level Product line (or product family) Source code But first, why do we want to decompose systems? The hierarchy shows a taxonomy of the system parts, but not the procedure for decomposing the system into parts — how do we do it? Why We Want To Decompose Systems Tackle complexity by “divide-and-conquer” See if some parts already exist & can be reused Focus on . | Ivan Marsic Rutgers University LECTURE 4: Software Architecture Topics Problem Structure vs. Solution Structure Software Architecture Definition Architectural Decisions & Key Concerns Architectural Styles Documenting Architecture: Views Hierarchical Organization of Software Software is not one long list of program statements but it has structure Taxonomy of structural parts (abstraction hierarchy), but not representation of relationships between the parts and does not specify the function of each part System or product Subsystems/Modules Packages Classes/Objects Methods highest abstraction level lowest level Product line (or product family) Source code But first, why do we want to decompose systems? The hierarchy shows a taxonomy of the system parts, but not the procedure for decomposing the system into parts — how do we do it? Why We Want To Decompose Systems Tackle complexity by “divide-and-conquer” See if some parts already exist & can be reused Focus on creative parts and avoid “reinventing the wheel” Support flexibility and future evolution by decoupling unrelated parts, so each can evolve separately (“separation of concerns”) Create sustainable strategic advantage Problem Structure Subsystems derived from the requirements (“bottom-up” approach or induction) Typical Software Eng. Problems 1. User works with computer system (problem domain is “virtual”, not physical) 2. Computer system controls the (physical) problem domain (user not involved) 3. Computer system intermediates between the user and the problem domain User System System Problem domain User System Problem domain User System Repository User System Problem domain User System Problem domain System IN doc OUT doc ) System transforms input document to output document ) User edits information stored in a repository ) System observes the problem domain and displays information ) System controls the problem domain as commanded by the user REQ-1: Map input .

• Kỹ thuật lập trình
• Software engineering
• Lecture Software engineering
• Software development methods
• Software architecture
• Problem structure
• Architectural decisions
• Object oriented software engineering
• Practical software development
• Object orientation
• Software quality
• Software engineering projects
• Introduction to software engineering
• Lecture Introduction to software engineering
• Công nghệ phần mềm
• Software process
• Software engineering ethics
• Professional software development
• Software process activities
• Software engineering diversity
• Introduction Software Engineering
• Software products
• FAQs about software engineering
• Essential attributes of good software
• Importance of software engineering
• Software processes
• Aspect oriented software engineering
• The separation of concerns
• Software engineering with aspects
• Quality concepts
• Detail Design
• Design Software Engineering
• Implementation Software Engineering
• Build Software Engineering
• Buy Software Engineering
• Requirement engineering
• Requirement engineering process
• Software requirements engineering
• Lecture Software requirements engineering
• Requirements engineering
• Software requirements engineering
• Lecture Software requirements engineering
• System engineering
• Software requirements document
• Requirements engineering process tasks