어쨌건간에 흘러가는 者

본 포스트는 개인 스터디 용으로 작성된 Ian Sommerville의 Software Engineering, 8/E의 요약본입니다.

1. Object-oriented development
- Object-oriented analysis, design and programming are related but distincted.
- OOA is concerned with developing an object model of the application domain.
- OOD is cencerned with developing an object-oriented system model to implement requirements
- OOP is cencerned with realising an OOD using an OO programming language

2. Characteristics of OOD
- Objects are abstractions of real-world or system entities and manage themselves
- indenpendent with each other, encapsulate state, communicate by message passing

3. Objects and object classes
- Objects are entities in a S/W system which represent instances of real-world and system entities
- Object classes are templates for objects

4. UML
- An integration of notations which describe object oriented analysis and designs
- De facto standard for object oriented modelling

5. Object communication
- Conceptually, objects communicate by message passing
- In practice, messages are often implemented by procedure calls(procedure name and parameter list)

6. Generalisation and inheritance
- Classes may be arranged in a class hierarchy where one class (a super-class) is a generalisation of one or more other classes (sub-classes)
- A sub-class inherits the attributes and operations from its super class and may add new methods or atributes of its own
- Advantages : Inheritance classify entities, make reuse mechanism at both the design & the programming level, and provide organisational knowledge about domains and systems.

7. An object-oriented design process : Structured design processes
- involve developing a number of differnet system models
- require a lot of effort for development and maintenance of these models
- For small systems, this may not be cost-effiective
- However, for large systems developed by different groups design models are an essential communication mechanism

8. Process stages
1) Define system context and model of system use : A static model that describes other systems in the environment, a dynamic model that describes how the system interacts with its environment(Use Case used)
2) Design the system architecture : e.g. layered architecture(several layered sub-system composition). There should normally be no more than 7 entities in an architectural model
3) Identify the principal system objects:
  - Grammatical approach (based on natural lagnuage)
  - idenfitying concrete things in the application domain
  - Behavioural approach (what participates in what behaviour)
  - Scenario-based analysis (objects in scenario)
4) Develop design models
  - Static model : show relationships between object classes
  - Dynamic model : show relationships between objects
  - e.g. sub-system model, sequence model, state machine model(statechart), use-case models, aggregation, generalisation model, etc.
5) Object interface specification
  - Object interfaces have to be specified so that the object and other components can be designed in parallel
  - UML uses class diagram

본 포스트는 개인 스터디 용으로 작성된 Ian Sommerville의 Software Engineering, 8/E의 요약본입니다.

1. Software architecture
- Architectural design is the process for identifying the sub-system and the framework for sub-system control & communication
- Software architecture is the output of architectural design.

2. Architectural design
- represents the link between specification and design processes : early stage of the system design process.

3. Architecture and system characteristics
- Performance : large components rather than fine-grain components
- Security : critical assets in the inner layers
- Safety : localise safety-critical features
- Availability : mechanism for fault tolerance
- Maintainability : fine-grain, replacable components

4. Architectural conflicts
- maintainability vs performace
- availability vs security
- safety vs performance

5. System structuring
- concerned with system decomposition
- The architectural design is expressed as a block diagram
- (if more detailed) show data flowing and interface of sub-systems

6. Architectural styles(Architectural models)
- Main objective of using generic architectural model or style is reuse.

comment:
Sommervile seems to use both terms('style' and 'model') with the same meaning.

- can include models like :
   1) Static structural model : shows sub-systems or components that are developed as a seperate unit
   2) Dynamic process model : shows how the system is composited as processes in run-time
   3) Interface model : defines services provided by sub-systems that are revealed via public interfaces
   4) Relationships model : shows the relationship(e.g. data flow) among sub-systems
    5) Destribution model : shows how sub-systems are distributed
- system orgranization model : reflect base strategy for defining system structure. but sub-system model includes more details.
   1) Repository model : based on public database
   2) Client/Server model : distributed architecture(effective for network based system)
   3) Abstract machine(layered) model : ease for incremental development.

7. Modular decomposition
- Another structural level where sub-systems are decomposing into modules
- Two modular decomposition model types
    1) Object models : when implemented, objects are created from object classes and some control model is used to operate these.
    2) Data-flow(pipeline) models : functional transformation process their imputs to produce outputs

sub-systems and modules are different on dependency among each element. Sub-system is independent with other sub-systems, but module is not.

8. Control styles
- are concerned with the control flow between sub-systems and distincted from the decomposition model
- Control style types
    1) Centralised control : One sub-system has overall responsibility for control. It starts and stops other sub-systems.
    2) Event-based control : Broadcast models / Interrupt-driven models

9. Reference architecture
- Architectural models tend to be specific to some application domain
- two types of domain-specific model
    1) Generic models : bottom-up models
   2) Reference models : top-down models which are derived froms as study of the application domain rather than existing systems.