Software Engineering BFH

• Concepts
• Associations
• Attributes
• NOT operations --> Similar Class Diagram

• Check for Typical Classes
• Noun Phrase Identification
• Responsibility-Driven Design (RDD)

• Doing
• Knowing

• Class
• Responsibilities: What is the class doing?
• Collaborators: Does it know / need other classes

Use Cases -> System Context -> Architecture -> Class Model -> Design Models -> Implementation

•  low-level pattern > describes the implementation of aspecifig aspect of a software component,

• common structure of interacting objects to solve a general sw-design problem in a specifig context
• Generic
• Language independent

• high-level pattern, descibes the fundamental structure of a sw-system and relations among it's participating sub-systems

• Creational
• Structural
• Behavioral

1. enable large scale reuse of S/W

2. Helps in improve developer communication

3. capture expert knowledge and design trade-offs and make expertise widely available

4. Well documented and understood

1.Do not lead to direct code reuse

2. Complex in nature

3. they are deceptively simple

4. they are validated by experince and discussion

an approach to software development in which a system is represented as a set of models that can be automatically transformed to executable code.

• A model that describes how the sw is organized as :
  • a set of components
  • which communicate with each other

• early stage of system design process
• often parallel with spec activities

• link between RE and sw design --> based on / parallel with context and domain model

• individual programs (and their components)
• complex enterprise systems --> composed of other systems, programs, components
  • distributed over different computers
  • owned by different companies

• Stakeholder communication
  • sh can understand the system and discuss --> no confusing detail
• System analysis
  • analysis if the system can meet it's nf requirements
• Project planning
  • planning & assigning responsibilities / ressources
  • planning the interfaces and integration
• Documentation
  • Complet model that shows
    • the differnt components in a system
    • interfaces
    • connections
• Large-scale reuse
  • Architecture may be reusable
  • Generic product may be developed in form of  a framework

• Block diagrams (entities, relationships)  > boxes and lines
  • very abstract
    • For stakeholders and project planing
    • Cons: no types of relationships and no properties
• UML
  • structure: component, package, deployment D.
  • behavior: activity D.
  • interaction: communication D and interaction overview
    • For discusion with impl team, detailed planning, Model-Driven Engineering
    • Cons: high effort for creation & maintainance

• creative process
• depending on type of system

• How to decompose into modules?
• How to deploy on different machines?
• Control strategy?
• Is there a generic application architecture that can be used?
• Architectural patterns?

This has large impact on non fon-functional properties!

• ++ how to evaluate the arch. design?
• ++ how to document the architecture

• Performance (localise critical operations and minimise communication)
• Security (Layered architecture with critical assets in the inner Layers)
• Safety (Localise safety-critical features in a small number of sub-systems)
• Availability (redundant components and mechanisms for fault tolerance)
• Maintainability (fine-grain, replacable components)
• Scalability (distributed architecture to have options for load balancing)

1. MVC / MVP
2. Layering
3. Client-Server and P2P
4. Repository
5. Pipe and Filter

• Data processing applications
  • batch processing without user intervention
    • Scientific computing (CERN, ATLAS...)
• Event processing systems
  • Actions of app depending on events from outside
    • sensor networks(environment or patient health monitoring)
• Transaction processing applications
  • Data-centered
  • process user requests and update infos in db
    • e-commerce, reservaton systems...
• Language processing systems
  • Userinput in formal language is processed and interpreted
    • Compilers, databases, command interpreters

May be based on the Pipe & Filter Architecture Pattern

May be based on a Layer Architecture Pattern

Web-Shop:

• UI > Web browser
• apspecific layer includes additional functionality > shoping cart
  • add items in separate transactions
  • pay for all together in a single transaction
• Often implemented as Multi-tier Client-Server Architecture
  • Web Server: responsible for user communication with the UI (Browser = client)
  • Application Server: responsible for application specific logig, info storage, retrieval request
  • DB-Server: moves info to and from db and handles transaction management

tbd

tbd

• Combine architecture with (partial) implementation
• Component-based design
• Made of abstract and concrete classes and the interfaces between them
• Components are impolemented by:
  • filing in the missing parts of the design
  • by instantiaiting the abstract classes
• moderately large entities that can be reused

Library

• handle prticular task (XML parsing, error logging...)

Frameworks

• Most define the general controll flow / event handling
• include libraries
• Web-app framework: provide user session management, data storage, web page template system
• Desktop-app framework: ui and standard widgets

• System infrastructure f.
  • development of system infrastructure(communications, user interfaces., compilers)
• Middleware integration f.
  • component communication and information exchange
• Enterprise application f.
  • development of business specific apps

maximizing reuse & maximizing flexibility

Pro:

• Efficiency
• Security
• Expense
• Support

..tbc

Cons:

Security

Restrictions

Learning a framework, not a language

..tbc

Object-oriented design is the process of planning a system of interacting objects for the purpose of solving a software problem.

It is one approach to software design.