Docsity
Docsity
Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity

Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan

Guidelines and tips
Guidelines and tips
Sell on Docsity
Sell on Docsity
Docsity AI
Docsity AI
Log inSign up

Prepare for your exams

Study with the several resources on Docsity

Find documents

Prepare for your exams with the study notes shared by other students like you on Docsity

Search for your university

Find the specific documents for your university's exams

Docsity AINEW

Summarize your documents, ask them questions, convert them into quizzes and concept maps

Explore questions

Clear up your doubts by reading the answers to questions asked by your fellow students

Earn points to download

Earn points by helping other students or get them with a premium plan

Share documents
download point icon20 Points

For each uploaded document

Answer questions
download point icon5 Points

For each given answer (max 1 per day)

All the ways to get free points
Get points immediately

Choose a premium plan with all the points you need

Study Opportunities

Choose your next study program

Get in touch with the best universities in the world. Search through thousands of universities and official partners

Community

Ask the community

Ask the community for help and clear up your study doubts

Free resources

Our save-the-student-ebooks!

Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors

software engineering: design & architecture, Study notes of Software Engineering

Cairo UniversitySoftware Engineering

it's just a reminder of the most important points, notes, and definitions of the software design and architecture including design patterns and taxonomy.

Typology: Study notes

2022/2023

Available from 01/18/2023

angela_butterflies
angela_butterflies 🇪🇬

2 documents

1 / 6

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
(software/system) lifecycle model: is a description of the sequence of activities carried out in a
software project, and the relative order of these activities.
Traditional models for the phased development is document-driven
The Waterfall Model:
1 - User Requirements
2 - Software Requirements
3 - Architecture Design
4 - Detailed design & Coding
5 - Testing
6 – Delivery
Agile Methods:
View the world as chaotic
Individuals and interactions over processes and tools
Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
The development cycles are small/incremental
Sprint framework
Roles
o Product owner
o The scrum master
o The team (Cross-functional)
Ceremonies
o Sprint planning
o Sprint review
o Sprint retrospective
o Daily scrum meeting
Artifacts
o Product backlog
o Sprint backlog
o Burn down charts
OOP principles: (Differ from SOLID principles)
Encapsulate what varies
Code to an interface rather than to an implementation
Abstraction
pf3
pf4
pf5

Partial preview of the text

Download software engineering: design & architecture and more Study notes Software Engineering in PDF only on Docsity!

(software/system) lifecycle model: is a description of the sequence of activities carried out in a software project, and the relative order of these activities. Traditional models for the phased development is document-driven The Waterfall Model:  1 - User Requirements  2 - Software Requirements  3 - Architecture Design  4 - Detailed design & Coding  5 - Testing  6 – Delivery Agile Methods:  View the world as chaotic  Individuals and interactions over processes and tools  Working software over comprehensive documentation  • Customer collaboration over contract negotiation  • Responding to change over following a plan  The development cycles are small/incremental Sprint framework  Roles o Product owner o The scrum master o The team (Cross-functional)  Ceremonies o Sprint planning o Sprint review o Sprint retrospective o Daily scrum meeting  Artifacts o Product backlog o Sprint backlog o Burn down charts OOP principles: (Differ from SOLID principles)  Encapsulate what varies  Code to an interface rather than to an implementation  Abstraction

 Classes are about behaviors not functionality SOLID principles  Single responsibility o Each class should have only one reason to change  Open/close principle o Classes are open for extension, close for modification  Liskov substitution principle o ش استبدل االب باالبن يبقى العالقة مش صحيحه و الزم تتشاللو مقدرت o Replace the “inheritance” with an “aggregation” o Or: encapsulate what varies  Dependency inversion principle o One should depend upon abstraction not concretion o High level modules shouldn’t depend on low level modules  Interface segregation principle o Break a fat interface into many separate interfaces DP Description  Design name  Design intent (problem)  Solution

  1. Structure: UML class diagram
  2. Participants: the responsibilities of the participating classes
  3. Collaborations: relationships between participating classes  Context : the elements that make up the pattern
  4. Motivation
  5. Applicability
  6. Consequences Taxonomy for Design Patterns
  7. scope
  • Class  Relationships between classes and their subclasses.  Static-fixed at compile time.  eg. Inheritance
  • Object  object relationships  dynamic at runtime  eg. aggregation

 The Model-View-Controller pattern o Model: programmatic representation of the application's data, contains functionality for loading itself from permanent storage. o View:

  • Responsible for rendering the Model for presentation to the user.
  • does not itself store data or maintain state and is often updated independently from the Controller or the Model o Controller: contains the main application logic. o Patterns inside MVC:
  • Observer pattern (model notifies different views)
  • Strategy Pattern (more than one controller)
  • Composite pattern (the view containing the GUI elements) Service Oriented Architecture& Web services Service: some functionality that is exposed for use by other processes. Web service is functionality that is exposed and would be accessed through web technologies. SOAP REST request to the API is an HTTP POST request with an XML request body REST APIs can be called with all of the HTTP verbs. To get a resource, a GET request is used. The request body is a type of SOAP wrapper that identifies the requested API, and a SOAP body that holds the request parameters. a REST API accepts GET parameters from the URI The response, just like the request The response is a JSON file with the data requested The software architecture of the system: is the set of structures needed to reason about the system
  • Elements
  • Relationships
  • Properties of both The software design of the system: is designing the whole system including system architecture Mapping of Architectural Software Engineering Concepts
  • Components
  • Interfaces
  • Nonfunctional requirements
  • Functional requirements
  • Costly work
  • Subsystems
  • Services
  • Response time
  • Usecases
  • Change of subsystem intergaces

Analysis: Focus on application domain Design: Focus on solution domain Design window: Time in which design decisions have to be made. system analysis: Analysis results in:

  • nonfunctional requirements
  • constraints
  • use case model (system functionality)
  • object model (class diagram)
  • sequence diagram System design: Design results in:
  • design goals( the qualities of the system)
  • software architecture
  • boundary use cases Steps:
  1. Start with the analysis model.
  2. Identify the design goals.
  3. Design an initial system decomposition. Hints for grouping objects into subsystems:
  • Assign objects identified in one use case into the same subsystem.
  • Create a dedicated subsystem for objects used for moving data among subsystems.
  • Minimize the number of associations crossing subsystem boundaries.
  • All objects in the same subsystem should be functionally related. Design Trade-offs:
  • Functionality v. Usability
  • Cost v. Robustness
  • Efficiency v. Portability o Efficiency: low execution time o Portability: works across different operating systems without code modification. Subsystem:
  1. Provides services to other subsystems
  2. A subsystem consists of a collection of classes, associations, operations, events and constraints that are closely interrelated with each other
  3. In UML subsystems are modeled as packages Service:
  4. A set of related operations that share a common purpose