Kbckbc's Blog - Bravo my life!

1. Software Characteristics
   1. Complexity
      1. hardware 보다 복잡
      2. component 간의 관계 파악 힘듬
   2. Flexibility
      1. 수정이 용이하다
   3. Development
      1. maintenance 가 development 보다 길다
   4. Maintenance
      1. 제품의 변경이 자주 일어난다
   5. Testability
      1. software 를 완전히 test 하는게 불가능하다
   6. Error sensitivity
      1. 작은 error 가 재앙을 불러올 수 있다.
   7. Standardization
      1. 표준화가 다른 분야에 비해 덜 되어 있다.
   8. Developer
      1. 개발자가 프로그램을 개발 하고자 하는 해당 분야를 잘 모른다.
   9. Maintainers
      1. 유지하는 사람이 개발하는 사람보다 더 실력이 좋아야 하는데 현실은 그렇지 못하다
2. Principle
   1. Abstraction
   2. Modularization
   3. Information hiding
   4. Encapsulation
   5. Hierarchy
   6. Decomposition
   7. Refinement
3. Desirable properties
   1. Understandability
   2. Modifiability
   3. Maintainability
   4. Reusability
   5. Testability
   6. Reliability
4. Modularity
   1. 큰 System 을 하나의 Module 에 전부 구현하지 않고 여러 module 별로 나누어 하나의 unique 한 기능을 하고(high cohesion), 다른 module 에 의존성을 줄이는 방향(low coupling) 으로 system 을 module 화 하는 것
   2. 장점
      1. design 과 개발을 module 별로 할 수 있다.
      2. 약간의 수정이 필요하지만 module 의 reuse 가 용이하다.
5. Cohesion
   1. how strongly related and focused the responsibilities of an elements are.(element 의 목적을 수행하기 위한 기능이 어떻게 관계를 가지고 집중되어 있는지를 나타낸다.)
   2. High cohesion - element 의 기능이 밀접하게 related 되고 focused 되어 있어서 하나의 unique 한 기능을 수행한다.
6. Coupling
   1. a measure of how strongly on element is connected to, has knowledge of, or relies on other elements.(한 element 가 다른 element와 얼마나 강하게 연결이 되어 있는가?)
   2. Low coupling - 하나의 element 가 다른 element 들에게 강하게 rely 하지 않으며 약하게 connect 되어 있다.
7. Abstraction
   1. A process whereby we identify the important aspect of a phenomenon and ignore its details.(중요하다고 생각 되는 viewpoint 를 정의하여 관심있는 부분만 부각시키고 detail 은 무시한다.
8. Information hiding
   1. It is the hiding of design decisions in a computer program that are most likely to change, thus protecting other parts of the program from change if the design decision is changed.(design decision 을 숨겨서 변화에 따른 영향을 최소화 한다.)
9. Encapsulation
   1. Information hiding 을 구현하는 하나의 mechanism.(필요한 기능들을 모아서 외부로 보일것과 숨길 것을 구분함으로써 Information hiding 을 지원)
10. Separation of Concerns
    1. 문제의 독립적인 현상을 파악하고 해당문제에 집중할 수 있도록 해준다.
11. Incrementality
    1. 커다란 System 을 구성할 때 점진적으로 확장시키는 방법

Chapter #1 : Object-Oriented Analysis and Design

1. Analysis
   1. Investigation of the problem and requirements rather than a solution.
   2. "Do the right thing"
2. Design
   1. Requirements 를 수행하는 conceptual 한 solution 을 찾는것
   2. "Do the thing right"
3. "Use Case" -> "Domain Model" -> "Interaction Diagram" -> "Design Class Diagram"

Chapter #2 : Iterative, Evolutionary, and Agile

1. UP
   1. "iterative software development process" for building object oriented systems.
   2. iterative development
      1. requirements analysis, design, implementation, testing (Iteration) 을 반복적으로 수행
      2. 연속적인 enlargement 와 feedback 을 통한 refinement 가 multiple iteration 으로 달성됨.
2. UP Phase
   1. Inception : approximate basic, basic scope, business case
   2. Elaboration : refined vision, requirement 분석, core architecture, high risk mitigation
   3. Construction : iterative implementation
   4. Transition : test, deployment
3. Up Discipline
   1. Business Modeling : domain model artifact
   2. Requirement : functional, non-functional requirement
   3. Design : Design model artifact
   4. Implementation : implementation
4. Agile development
   1. rapid and flexible response to change
5. Agile principles
   1. 지속적으로 software 를 delivery 하여 customer 를 만족시키는 것
   2. 개발 완료 시점에서도 변화를 수용하여 바꾼다
   3. 개발자와 Stakeholder 들이 project 전체에 걸쳐서 협력한다.

Chapter #3 : Case Studies

Chapter #4 : Inception is Not the Requirements Phase

Chapter #5 : Evolutionary Requirements

1. Requirements
   1. system 이 가져야할 capability 와 condition
2. Types of Requirements(FURPS+)
   1. Functionality : feature, capabilities
   2. Usability : human factor, documentation
   3. Reliability : frequency of failure
   4. Performance : response time
   5. Supportability : adaptability, maintainability
   6. Implementation : resource limitation
   7. 부연 설명
      1. Functionality => functional requirement. 이것은 Use Case Model 에서 find 한다.
      2. except Functionality => non-functional requirements. Supplementary Specification 에서 find 한다.
3. Requirement 분석과 관계된 UP Artifact
   1. Use case Model : primarily for functional requirement
   2. Supplementary specification : primarily for all non-functional requirement
   3. Glossary : define noteworthy term
   4. Vision : summarizes high-level requirement
   5. Business Rule : describes requirements or policies that transcend one software project

Chapter #6 : Use Cases

1. Use cases are not diagrams they are not text.
2. There is nothing object-oriented about use case.
   1. Actor : It is something with behavior
   2. Scenario : specific sequence of actions and interactions between actors and the system
   3. Use case : It is a collection of related success and failure scenarios that describe an actor using a system to support a goal
3. Actor
   1. It is anything with behavior
   2. Primary and supporting actors will appear in the actions steps of the use case text.
   3. Primary actor
      1. has user goals fulfilled through using services of SUD(System Under Discussion)
      2. Why identify? to find user goals
   4. Supporting actor
      1. provide a service to the SUD
      2. often a computer system but could be an organization or person
      3. Why identify? to clarify external interfaces and protocol
   5. Offstatge actor
      1. has an interest in the behavior of the use case, but is not primary or supporting actor
      2. Why identify? to ensure all necessary interests are identified and satisfied.
4. Use case
   1. Success and failure 의 collection 을 통하여 user 가 system 을 통해 달성하고자 하는 goal 을 보여준다.
   2. Use case 를 통해 domain model, design model 을 이끌어 낼 수 있다.
   3. Use case 항목
      1. Use case name : 이름
      2. Primary actor : goal 의 달성을 위해 system 에 service 를 요청하는 actor
      3. Stakeholders and Interests : 누가 이 system 을 사용하며, 그들의 요구사항!
      4. Precondition : scenario 가 시작 전에 충족되어 있어야 하는 것
      5. Postcondition : scenario 가 끝나고 달성되어 있어야 하는 사항
      6. Main success scenario : typical success path does not include any condition or branching
      7. Extension : branches from main success scenario
      8. Special Requirement : related non-functional requirements
5. Essential Style writing : keep their user interface out, focus on intent
6. How to find Use Cases?
   1. Step1 : Choose the System boundary
   2. Step2 : Find Primary actors and goals
   3. Step3 : Define Use cases
7. What tests can help find useful use case?
   1. Boss test : 어떤 작업이 Boss 를 만족시키나?
      1. Ex) login in 을 하는 것이 상사를 만족 시키나? -> X
   2. EBP test : Elementary Business Process, 확실히 이해 못함
   3. Size test : 적절한 크기로 Use case 를 잡는다.
      1. Ex) Enter an Item ID -> 너무 작다 X
8. Use case Diagram
   1. Use case Diagram 과 Use case relationship 은 secondary work 이다. text 가 우선시 되어야 한다.
   2. simple use case diagram provides a succinct visual context diagram for the system
9. UP Phase 에서 본 관점
   1. Inception Phase
      1. 대부분의 Use case 들이 정의된다. 이중 가장 핵심적인 것 10% 정도가 detail 하게 정의된다. coding 작업은 시작하지 않는다.
   2. Elaboration Phase
      1. Elaboration 은 보통 여러 iteration 으로 나뉘는데 처음부터 coding 에 들어간다.(detail 하게 분석한 것 부터) 이것이 waterfall 과 iterative development 의 차이점이다. Elaboration 단계가 거의 끝날 즈음에는 Use case 의 90% 가 detail 하게 정의 되고 core 기능을 하는 software 가 있어야 한다. 나머지 부분은 Construction Phase 에서 처리한다.

Chapter #7 : Other Requirements

1. Use case are not the Whole story
2. Supplementary Specification
   1. capture and identifies other kinds of requirements, non-functional requirements, such as Usability Reliability
   2. URPS+ qualities attributes
   3. documentation
   4. hardware & software constraints
   5. application specific domain rule(business rules)
3. Glossary : define noteworthy terms
4. Vision : summarizes the "Vision" of the project. It shows big ideas
5. Business Rules : capture long-living rules or policies, such as Tax laws. project 통틀어 사용되는 rules 찾기

Chapter #8 : Iteration 1 - Basics

1. It is common that incremental development for the same use case across iterations.
2. What happened Inception?
   1. may last one week
   2. most actor, goals, and use cases named
   3. most use case written in brief format. 10 ~ 20 % of the use case are written in fully dressed detail
   4. most influential and risky quality requirements identified
3. On to Elaboration
   1. the core risky software architecture is "programmed" and "tested"
   2. the majority of requirements are discovered and stabilized
   3. major risk are mitigated
4. Used to rank across iteration
   1. Risk : both technical complexity and other factors
   2. Coverage : all major parts of the system are at least touched on in early iteration
   3. Critically : has high business value

Chapter #9 : Domain Models

1. domain model is a visual representation of conceptual class on real-situation objects in a domain, not software objects
2. It provides a conceptual perspective
   1. domain objects or conceptual classes
   2. associations between conceptual classes
   3. attributes of conceptual classes
3. Why Create a Domain Model??
   1. This similarity of naming between the domain model and the domain layer support "lower gap" between the software representation and our mental model of the domain.
   2. Representation gap 을 낮춰준다.
4. How to create a Domain Model?
   1. Find the conceptual classes
   2. Draw them in UML "class diagram"
   3. Add association & attributes
5. Three Strategies to find Conceptual class
   1. Reuse existing model
   2. Use a category list
   3. Identify noun phrases
6. A common mistake with Attributes and Classes
   1. domain model 만들때 class 로 표현되어야 하는걸 attribute 로 표현하는 경우가 종종 있다.
   2. Ex) Flight class 밑에 destination attribute 는 적절해 보이나? 얼핏 생가하면 destination 이 attribute 일 것 같지만 destination 이 간단히 설명될 수 있는게 아니다. 또 다른 class 로 빼내어 ID 만 가지게 하는 것이 바람직 하다.
7. Description class
   1. 적용할 만큼의 이해가 안감
8. Associations
   1. relation ship between classes that indicates some meaningful and interesting connection
   2. multiplicity defines how many instance of a class A can be associated with one instance of a class B
9. Attributes
   1. logical data value of an object
   2. - : private visibility
   3. + : public visibility
   4. / : derivable value
   5. {readonly} : read only
10. Relate conceptual class with association not with an attribute
11. UP Phase 에서 본 관점
    1. Domain Model 은 Inception 단계에서 하지 않고 Elaboration 단계에서 한다.

Chapter #10 : System Sequence Diagrams

1. "The use case text" and "its implied system events" are input to SSD creation
2. SSD operation 은 나중에 operation contract, Glossary, starting point for collaborating objects(가장중요한 역할)를 위해 이용됨
3. What are System Sequence Diagram?
   1. It is a picture that shows for one particular scenario of a use case the events that external actors generate their order and inter system events
4. Why SSD?
   1. system event 찾는데 도움을 준다.
   2. use case text 가 system event 를 imply 하고 있는데 그것을 concrete 하고 explicit 하게 만들기 위해서
5. How to Model SSD Involving Other External Systems?
   1. this is deferred until a later iteration in the case study, since this iteration does not include remote system collaboration
6. SSD are part of the USE Case Model
   1. a visualization of the interactions implied in the scenarios of use cases
7. UP Phase 에서 본 관점
   1. Inception - 이 단계에서는 SSD 생성 안함
   2. Elaboration - SSD 생성한다.

Chapter #11 : Operation Contracts

1. Operation Contract?
   1. It use a pre- and post- condition form to describe detail changes to objects in a domain model as the result of  a system operation
2. SSD 에서 정의된 system operation, domain model 이 Operation Contract 의 input 이고 Operation Contract 는 object design 시 이용된다.
3. What are the sections of a Contract?
   1. Operation : Name of operation
   2. Cross References : Use case this operation can occur within
   3. Precondition : Note worth assumptions
   4. Postcondition : the state of objects in the domain model after completion of the operation
4. How to create and write contract?
   1. Identify system operations from the SSDs.
   2. For system operations that are complex and perhaps subtle in their result or which are not clear in the use case, construct a contract
   3. To describe the post conditions, use the following categories
      1. Instance creation and deletion
      2. attribute modification
      3. associations formed and broken
5. UP Phase 에서 본 관점
   1. Inception - 이 단계에서는 Operation Contract 생성 안함
   2. Elaboration - Operation Contract 생성한다.

Chapter #12 : Requirements to Design - Iteratively

1. The requirements and object-oriented analysis has focused on learning to do the "right things"; that is understanding some of the outstanding goals for the case studies, and related rules and constrains. By contrast, the following design work will stress "do the thing right"; that is, skillfully designing solution to satisfy the requirements for this iteration

Chapter #13 : Logical Architecture and UML Package Diagrams

1. UML package diagrams may illustrate the LA(Logical Architecture) as part of the Design Model.
2. Logical architecture
   1. It is the large-scale organization of the software classes into packages subsystems and layers.
   2. there's no decision about how these elements are deployed across different operating system process or across physical computers in a network.
   3. Typical layers in an OO system
      1. User Interface : User Interfaces
      2. Application Logic and Domain Objects : Software object representing domain concepts
      3. Technical Services : technical service 를 제공하는 object 혹은 subsystem
3. Software Architecture
   1. software Architecture 란 "Software system 의 구성(organization), structural elements 와 their interface 들의 선정(selection), structural behavior element 들의 조합(composition), 그리고 이러한 구성을 만드는 architectural style" 에 대한 decision 집합이다.
4. Essential idea of using layers
   1. organize the large-scale logical structure of a system into discrete layers of distinct related responsibilities.
   2. collaboration and coupling is from higher to lower layers
5. What is layer?
   1. 관련 있는 기능들(class, package, subsystem) 끼리 grouping 하는 것
6. What is layered architecture style?
   1. "higher layer" 가 "lower layer" 의 service 를 호출, 그러나 반대로는 일반적으로 일어나지 않는다.
7. Benefits of Using Layers
   1. separation of concerns, a separation of high from low-level services, and of application-specific from general service -> reduce coupling and dependencies improve cohesion
   2. some layers can be replaced with new implementation
   3. lower layer contain reusable functions
   4. development by teams is aided because of the logical segmentation
8. Information system logical architecture
   1. UI : GUI Window
   2. Application : handle presentation layer requests
   3. Domain : Implementation of domain rules
   4. Business Infrastructure : General business service
   5. Technical Services : high level technical services(security 등)
   6. Foundation : low-level technical services(DB, file 등)
9. What is the Relationship Between the Domain Layer and Domain Model?
   1. The domain layer is part of the software and the domain model is part of the conceptual-perspective analysis. They are not the same thing . But by creating domain layer with inspiration from the domain model, we achieve a lower representation gap between the real-world domain and our software design.
10. The Model-View Separation Principle
    1. Do no connect or couple non-UI objects directly to UI objects
    2. Do no put application logic in the UI object methods -> delegate request for application logic on to non-UI objects
    3. The motivation for Model-View Separation.
       1. to support cohesive model definition
       2. to allow separate development
       3. to minimize impact of requirement change

Chapter #14 : On to Object Design

1. "Dynamic modeling" vs "Static Modeling"
   1. Dynamic modeling
      1. such as UML interaction diagram.
      2. help design the logic, the behavior of the code or the method bodies
   2. Static Modeling
      1. such as UML class diagram
      2. help design the definition of packages, class name, attributes and method signature

Chapter #15 : UML Intreaction Diagrams

Chapter #16 : UML Class Diagrams

Chapter #17 : GRASP : Designing Objects with Responsibilities

1. Pattern
   1. Named description of a well-known problem & solution that can be applied to new context
2. Gang of Four(GoF) patter 은 23개, 저자가 4명.
3. GRASP define nine basic OO design principle or basic building blocks in design.
4. GRASP for basic patterns of assigning responsibilities, and GoF for more advanced design ideas.
5. Nine GRASP pattern
   1. Creator
   2. Controller
   3. Pure Fabrication
   4. Information Expert
   5. High Cohesion
   6. Indirection
   7. Low Coupling
   8. Polymorphism
   9. Protected Variations
6. Creator
   1. Problem : Who creates an A?
   2. Solution : Assign class B the responsibility to create an instance of class A if one of these are true.(당연하게 생각하자! 어떤 object 를 만드는데 엄한넘이 만들면 이상하잖아? 당연히 그걸 관리하는 사람이 만들어야지.)
      1. B "contain" A
      2. B "records" A
      3. B "compositely aggregate" A
   3. Ex) Who create the Square object? -> Board create Square
7. Information Expert(Expert)
   1. Problem : What is a basic principle by which to assign responsibilities to objects?
   2. Solution : Assign responsibility to the class that has the information needed to fulfill the responsibility. (정보를 가지고 있는 object(class) 가 그와 관련된 작업을 처리하는게 맞다.)
   3. Ex) Who knows about a Square object? -> Board!!
   4. Benefit
      1. Information encapsulation 이 유지된다. 자기 자신의 정보를 사용하기 때문에
      2. 자기 정보와 관련되 기능을 하기 때문에 cohesion 이 높아진다.
8. Low Coupling
   1. Problem : How to reduce the impact of change?
   2. Solution : Assign responsibilities so that coupling remains low
   3. Ex) Why Board over Dog? -> Dog(말) 이 Squared 의 정보를 알려고 직접 접근하는것 보다 Board 를 통해서 접근하는 것이 low coupling 이다. 전체적인 coupling 이 줄어들게 되는 것이다.
   4. Benefit
      1. 변경시 다른 component 에 미치는 영향이 작다.
      2. 이해도를 높여준다.
      3. reuse 를 용이하게 한다.
9. Controller
   1. Problem : What first object beyond the UI layer receives and coordinates a system operation?
   2. Solution : Assign responsibility for receiving or handling a system event message to a class representing one of the followings
   3. 두가지 Controller
      1. Facade controller
         1. 모든 system 을 control 한다. system event 가 그리 많지 않을 때 유용하다. bloated controller 가 되기 쉽다.
      2. Use case controller
         1. 각 use case 마다 다른 controller 를 갖는다. 이러한 controller 를 domain object 로 볼수는 없다. 많은 system event 에 적합합다.
   4. UI object need to delegate the request to domain objects in the domain layer
   5. Benefit
      1. reuse 를 용이하게 한다.
      2. interface 교체시 부담이 작아진다.
10. High Cohesion
    1. Problem : How to keep objects focused, understandable, and manageable and as a side effect, support low coupling?
    2. Solution : Assign responsibilities so cohesion remain high
    3. Benefit
       1. maintenance & enhancements are simplified.
       2. low coupling is supported
       3. reuse 가 쉽다
       4. design 의 clarity & ease of comprehension is increased
    4. Cohesion : how strongly related and focused the responsibilities of an element are
    5. Coarse-Grained Remote Interface
       1. Remote operation 을 하는 object 는 cohesion 이 낮아지지만 모든 기능을 한 곳에서 처리하게 할 수도 있다. performance 가 높아지고 관리상에 이점이 있기 때문에.
       2. Ex) DB 접근하는 SQL Query 문이 각각의 class 마다 퍼져있다면 찾아서 수정하기가 힘들다. 이것을 한곳에 모아 놓으면 Cohesion 을 헤치게 되나 다른 이점이 있다.
11. Modular Design
    1. Modularity is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules.
    2. It is strongly related to coupling modules.
12. Contradictions
    1. In a few cases accepting lower cohesion is justified.
    2. CASE #1
       1. Suppose an application contains embedded SQL statements. There is one SQL expert.
       2. Solution : Group all the SQL into one class.
    3. CASE #2
       1. Distributed server objects.
       2. Solution : It is sometimes desirable to create fewer & larger, less cohesive server object.
          

Chapter #18 : Object Design Examples with GRASP



Chapter #19 : Designing for Visibility

1. Visibility
   1. It is the ability of an object to "see" or have a reference to another object.
   2. Attribute Visibility
      1. Attribute visibility from A to B exists when B is an attribute of A.
      2. Relatively permanent visibility because it persists as long as A and B exist.
   3. Parameter Visibility
      1. Parameter visibility from A to B exists when B is passed as a parameter to a method of A.
      2. Relatively temporary visibility because it persists only within the scope of the method.
      3. It is common to transform parameter visibility into attribute visibility.
   4. Local Visibility
      1. Local visibility from A to B exists when B is declared as a local object with a method of A.
      2. Relatively temporary visibility because it persists only within the scope of the method.
      3. It is common to transform locally declared visibility into attribute visibility.
      4. Two common means by which local visibility is achieved are.
         1. Create new local instance and assign it to a local variable.
         2. Assign the returning object from a method invocation to a local variable.
   5. Global Visibility
      1. Global visibility from A to B exists when B is global to A.
      2. Relatively permanent visibility because it persists as long as A and B exist.
      3. The preferred method to achieve global visibility is to use the "Singleton".

Chapter #20 : Mapping Designs to Code

1. Creating class definitions from DCDs
   1. Defining a class with Method Signature & Attributes.
2. Creating methods from interaction diagrams
   1. The sequence of the messages in an interaction diagram translates to a series of statements in the method definitions.
3. Collection classes in code
   1. One-to-Many relationships are usually implemented with the introduction of a collection object.
4. Exceptions & Error handling
5. Order of Implementation
   1. Classes need to be implemented from least-coupled to most-coupled.
6. Test-Driven or Test-First Development.

Chapter #21 : Test-Driven Development and Refactoring

1. Test-Driven Development(TDD)
   1. Test code is written before the class to be tested, and the developer writes unit testing code for nearly all production code.
   2. Advantages
      1. The unit tests actually get written
         1. Human nature is such that avoidance of writing unit tests is very common.
      2. Programmer satisfaction leading to more consistent test writing
         1. First writes the production code, and then as an afterthought is expected to add unit tests, it doesn't feel satisfying. It's human psychology. If test is written first we feel a worthwhile challenge and question in front of us. After the code is cut to pass the test, there is some feeling of accomplishment
      3. Clarification of detailed interface and behavior
         1. If you're in writing test code, you must think through the details of the public view of the method.
      4. Provable, repeatable, automated verification.
         1. Having hundreds or thousands of unit tests provides some meaningful verification of correctness
      5. The confidence to change things.
         1. Unit test suite providing immediate feedback if change caused an error.
   3. Each testing method follows this pattern
      1. create the fixture(fixture:The thing to be tested)
      2. Do something to it(some operation that you want to test)
      3. Evaluate that the results are as expected.
2. Refactoring
   1. It is a structured, disciplined method to rewrite or restructure existing code without changing its external behavior, applying small transformation steps combined with re-executing tests each step.
   2. The essence of refactoring is applying smell behavior preserving transformations(each called a 'refactoring'), one at a time
   3. Good programming
      1. Remove duplicate code.
      2. Improve clarity.
      3. Make log methods shorter
      4. remove the use of hard-coded literal constants
   4. Code smells
      1. Duplicate code.
      2. Big method.
      3. Class with many instance and variables
      4. Class with lots of code
   5. Examples of Refactorings
      1. Extract method
      2. Long method -> shorter method
      3. Extract constant
      4. Introduce Explaining variable
      5. Replace Constructor call with Factory Method

Chapter #22 : UML Tools and UML as Blueprint

1. Computer Aided Software Engineering(CASE)
   1. Forward engineering
      1. Generation of code from diagram.
   2. Reverse engineering
      1. Generation of diagrams from code.
   3. Round-trip engineering
      1. The tool supports generation in either direction.

Chapter #23 : Iteration 2 - More patterns

1. From Iteration 1 to 2
2. Iteration-2 Requirements and Emphasis
   1. Iteration-2 largely ignores requirements analysis and domain analysis and focuses on object design with responsibilities and GRASP, and applying some GoF design pattern

Chapter #24 : Quick Analysis Update

1. Case Study : NextGen POS
   1. Use cases
      1. No refinement is needed for the use cases this iteration
   2. SSD
      1. This iteration includes adding support for third-party external system with varying interfaces
   3. Domain Model
      1. It is quite reasonable to skip refining Domain model, move quickly on to design work and let the discovery of new domain concepts occur during object design in the design model when the developers are thinking through a solution, or indeed even while coding
   4. System Operation Contract
      1. No new system operations are being considered in this iteration and thus contracts are not required.
2. Case study : Monopoly
   1. Generalization is the activity of identifying commonality among concepts and defining superclass and subclass relation ships
   2. Create a conceptual subclass of a superclass when
      1. The subclass has additional attributes of interest.
      2. The subclass has additional association of interest.
      3. The subclass concept is operated on, handled, reacted to, or manipulated differently than the super class or other subclasses, in noteworthy ways

Chapter #25 : GRASP : More Objects with Responsibilities

1. Polymorphism
   1. Problem
      1. How handle alternatives based on type? How to create pluggable software components?
   2. Solution
      1. When related alternatives or behavior vary by types, assign responsibility for the behavior using polymorphic operations to the types for which the behavior varies.
      2. It is a fundamental principle in designing how a system is organized to handle similar variations. A design based on assigning responsibilities by polymorphism can be easily extended to handle new variations.
      3. As a rule-of-thumb, if there is a class hierarchy with an abstraction superclass C1, consider making an interface I1 that corresponds to the public method signatures of C1, and then declare C1 to implement the I1 interface.
   3. Benefit
      1. Extensions required for new variations are easy to add.
      2. New implementations can be introduced without affecting clients.
2. Pure Fabrication
   1. Problem
      1. There are many situations in which assigning responsibilities only to domain layer software classes leads to problem in terms of poor cohesion or coupling or low reuse potential.
   2. Solution
      1. Assign a highly cohesion set of responsibilities to an artificial or convenience class that does not represent a problem domain concept - something made up to support high cohesion, low coupling, and reuse. Such a class is a Fabrication of the imagination.
   3. Design of Objects.
      1. Representational decomposition
         1. The software class is related to or represents a thing in a domain.
      2. Behavioral decomposition
         1. We desire to assign responsibilities by grouping behaviors or by algorithms without any concern for creating class with a name or purpose that is related to a real-world domain concept.
         2. These convenience classes are usually designed to group together some common behavior, and are thus inspired by behavioral rather than representational decomposition.
3. Indirection
   1. Problem
      1. Where to assign a responsibility, to avoid direct coupling between two(or more) things? How to de-couple objects so that low coupling is supported and reuse potential remains higher?
   2. Solution
      1. Assign the responsibility to an intermediate object to mediate between other components or services so that they are not directly coupled.
   3. Benefit
      1. Lower coupling between components.
4. Protected Variation
   1. Problem
      1. How to design objects, subsystems, and systems so that the variations or instability in these elements does not have an undesirable impact on other elements.
   2. Solution
      1. Identify points of predicted variation or instability; assign responsibilities to create a stable interface around them.
   3. Don't talk to Strangers(Law of Demeter)
      1. It means to avoid creating design that traverses long object structure paths and send message to distant, indirect objects
      2. The farther along a path the program traverses, the more fragile it is. Why? Because the object structure(The connections) may change.
   4. Information Hiding
      1. David Parnas introduces the concept of information hiding. Perhaps because the term sounds like the idea of data encapsulation, it has been misinterpreted as data encapsulation, and some books erroneously define the concepts as synonyms. Rather, Parnas intended information hiding to mean hide information about the design from other modules, at the points of difficulty or likely change. To quote his discussion of information hiding as a guiding design principle.

      2. 'We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others.

      3. That is, Parnas's information hiding is the same principle expressed in PV, and no simply data encapsulation - which is but one of many techniques to hide information about the design. however, the term has been so widely reinterpreted as a synonym for data encapsulation that it is no longer possible to use it in its original sense without misunderstanding.
   5. Open-Closed Principle
      1. Modules should be both open and closed.

Chapter #26 : Applying GoF Design Patterns


Chapter #27 : Iteration 3 - Intermediate Topics

Chapter #28 : UML Activity Diagrams and Modeling

Chapter #29 : UML State machine Diagrams and modeling

Chapter #30 : Relating Use Cases

Chapter #31 : Demain Model Refinement

Chapter #32 : More SSDs and Contracts

Chapter #33 : Architectural Analysis

Chapter #34 : Logical Architecture Refinement

Chapter #35 : Package Design

Chapter #36 : More Object Design with GoF Patterns

Chapter #37 : Designing a Persistence Framework with Patterns

Chapter #38 : UML Deployment and Component Diagrams

Chapter #39 : Documenting Architecture: UML & the N+1 View Model

Chapter #40 : More on Itertive Development and Agile Project Management