'Inforamtion Technology'에 해당되는 글 281건

Our client - tailspin Toys...

- Small brick & mortar hobby shop that sells model airplanes

- Want an online store front to supplement in-store sales

: Define the solution's boundaries

: Identify Who will impacted by the solution

: Discover what valuable activities will be automated 

: Uncover constraints that will limit the solution

: Kick-start the requirements gathering process

- Warnings

: Not standard UML

: More in common with mind-mapping techniques

-Tip

: Limit workshops to about 1hour each

: Always start with a vision of solution (context)

: Clearly identify who lives inside and outside the system(Scope)

: Describe goals from users' point of view(business value)

: Generate lots of ideas and capture everything

Tips

- Think of actors as roles, not job titles

- Use business domain terminology

- Focus on actor's goals, not implementation details

- Use strong, active verbs in the names

- Focus on only one "feature area" in a single diagram

- Stack cases in diagrams to show relative order

- Use color and notes to document important details

Domain Modeling Tips

- Use Friendly name (spaces, no abbreviations)

- Show just those classes needed in descriptions of the requirements

- Focus on names and simple relationship(associations)

    : Don't worry about aggregation or composition - that comes later in detailed design

- Capture multiplicities to clarify the relationships

- Add attributes, and types only if they needed to clarify a requirement

    : Stick with standard primitives for attribute types : Boolean, Integer, String

    : Add domain specific types if they add clarity (Temperature: Celcius , Duration: Weeks)

- Stay implementation - independent

    : Don't assign visibilities - that's comes later in detailed design

    : Avoid modeling keys or IDs - they are an implementation detail

    : Avoid modeling verbs/actions/operation/functions

Activity Diagram

- Next generation flow charts

- Used to show processes

    : business processes

    : work flows

    : algorithms

- Complementary to use cases

    : Show task flow instead of structure

Tips

- Use Tem to capture and validate business processes

- think in terms of users' actions

- Focus on actions that are visible from outside the system

- Use to show flow of actions that span multiple use cases

- Best diagram for showing parallel operations

- Focus on only one "activity" in each diagram

http://blogs.msdn.com/vsarch
http://www.notsotrivial.net

 [Reference Book]
1.Brain Storming
Managing Software Requirements
the Rational Unified Process Made Easy
user Stories applied

2.Use Case Modeling
Use Case Modeling
Use Case : patterns and Blueprints
UML 2 and the Unified Process

3.Domain Model
Domain Driven Design
Use Case Driven Object Modeling with UML

4.Capturing Business Workflow
UML 2 and the Unified Process
UML Distilled
Use Case Modeling

5.architecting an application Using A layer Diagram
Microsoft application Architecture Guide - 2nd edition
Architecting Applications for the Enterprise
Domain Driven Design

6.Component Modeling
The unified Modeling Language User Guide - 2nd Edtion
UML Distilled - 3rd Edtion
the Elements of UML 2.0 Style

7.Sequance Diagram Modeling
UML 2 and the Unified Process
elements of UML 2.0 Style
Use Case Modeling

8.Class Modeling
UML 2 and the Unified Process
elements of UML 2.0 Style
Use Case Drive Object Modeling with UML

9.Organize models
Domain Driven Design
Patterns of Enterprise application Architecture
Architecting Applications for the Enterprise

default:
  # Outgoing emails configuration (see examples above)
  email_delivery:
    delivery_method: :smtp
    smtp_settings:
     
      address: ip를 넣는다.

      port: 25
      domain: domain을 넣는다.
      authentication: :none <= ":"를 넣음에 주의

옵션 설명

-p 각 커밋에 적용된 패치를 보여준다.
--stat 각 커밋에서 수정된 파일의 통계정보를 보여준다.
--shortstat `--stat` 명령의 결과 중에서 수정한 파일, 추가된 줄, 삭제된 줄만 보여준다.
--name-only 커밋 정보중에서 수정된 파일의 목록만 보여준다.
--name-status 수정된 파일의 목록을 보여줄 뿐만 아니라 파일을 추가한 것인지, 수정한 것인지, 삭제한 것
인지도 보여준다.
--abbrev-commit 40자 짜리 SHA-1 체크섬을 전부 보여주는 것이 아니라 처음 몇 자만 보여준다.
--relative-date 정확한 시간을 보여주는 것이 아니라 `2 주전`처럼 상대적인 형식으로 보여준다.
--graph 브랜치와 머지 히스토리 정보까지 아스키 그래프로 보여준다.
--pretty 지정한 형식으로 보여준다. 이 옵션에는 oneline, short, full, fuller, format이 있다. format
은 원하는 형식으로 출력하고자 할 때 사용한다.

조회 제한 조건

-(n) 최근 n 개의 커밋만 조회한다.
--since, --after 명시한 날짜 이후의 커밋만 검색한다.
--until, --before 명시한 날짜 이전의 커밋만 조회한다.
--author 입력한 저자의 커밋만 보여준다.
--committer 입력한 커미터의 커밋만 보여준다.

세 가지 상태
Git은 파일을 Commited, Modified, Staged 이렇게 세 가지 상태로 관리한다.

Commited : 데이터가 로컬 데이터베이스에 안전하게 저장됐다는 것을 의미한다.

Modified  : 수정한 파일을 아직 로컬 데이터베이스에 Commit 하지 않은 것을 말한다.

Staged    : 현재 수정 한 파일을 곧 Commit 할 것이라고 표시한 상태를 의미한다. 

 Git Directory, Working Directory, Staging Area

Git Directory : Git이 프로젝트의 메타데이터와 객체 데이터베이스를 저장하는 곳 , Git의 핵심이다.

다른 컴퓨터에 있는 저장소를 Clone 할 때 Git Directory가 만들어진다.

Working Directory :  프로젝트의 특정 버전을 Checkout 한 것이다. Git Directory는 지금 작
업하는 디스크에 있고 그 Directory에 압축된 데이터베이스에서 파일을 가져와서 Working  Directory를 만든다.

Staging Area :  Git Directory에 있다. 단순한 파일이고 곧 Commit 할 파일에 대한 정보를 저장한다

$ git status
# On branch master
nothing to commit (working directory clean)

$ git add README
git status 명령을 다시 실행하면 README 파일이 Tracked 상태이면서 Staged 상태라는 것
을 확인할 수 있다:
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: README
#

$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: README
#
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: benchmarks.rb
#

$ git add benchmarks.rb
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: README
# modified: benchmarks.rb
#

$ vim benchmarks.rb
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: README
# modified: benchmarks.rb
#
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: benchmarks.rb
#

$ git add benchmarks.rb
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: README
# modified: benchmarks.rb
#

$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: README
#
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: benchmarks.rb
#

$ git diff
diff --git a/benchmarks.rb b/benchmarks.rb
index 3cb747f..da65585 100644
--- a/benchmarks.rb
+++ b/benchmarks.rb
@@ -36,6 +36,10 @@ def main
@commit.parents[0].parents[0].parents[0]
end
+ run_code(x, 'commits 1') do
+ git.commits.size
+ end
+
run_code(x, 'commits 2') do
log = git.commits('master', 15)
log.size

$ git diff --cached
diff --git a/README b/README
new file mode 100644
index 0000000..03902a1
--- /dev/null
+++ b/README2
@@ -0,0 +1,5 @@
+grit

$ git add benchmarks.rb
$ echo '# test line' >> benchmarks.rb
$ git status
# On branch master
#
# Changes to be committed:
#
# modified: benchmarks.rb
#
# Changed but not updated:
#
# modified: benchmarks.rb
#

$ git diff
diff --git a/benchmarks.rb b/benchmarks.rb
index e445e28..86b2f7c 100644
--- a/benchmarks.rb
+++ b/benchmarks.rb
@@ -127,3 +127,4 @@ end
main()
##pp Grit::GitRuby.cache_client.stats
+# test line

$ git diff --cached
diff --git a/benchmarks.rb b/benchmarks.rb
index 3cb747f..e445e28 100644
--- a/benchmarks.rb
+++ b/benchmarks.rb
@@ -36,6 +36,10 @@ def main
@commit.parents[0].parents[0].parents[0]

$ git commit

$ git commit -m "Story 182: Fix benchmarks for speed"
[master]: created 463dc4f: "Fix benchmarks for speed"
2 files changed, 3 insertions(+), 0 deletions(-)
create mode 100644 README

$ git status
# On branch master
#
# Changed but not updated:
#
# modified: benchmarks.rb
#
$ git commit -a -m 'added new benchmarks'
[master 83e38c7] added new benchmarks
1 files changed, 5 insertions(+), 0 deletions(-)

기본 아이디어

- Adapter 패턴은 클래스의 인터페이스를 클라이언트가 기대하는 다른 인터페이스로 변화(어댑팅)한다. 이는 호환성 없는 인터페이스 때문에 함께 사용할 수 없는 클래스를 개조하여 함께 작동하도록 해준다.

// ResultSet interface를 구현한 ResultSetAdapter

public class ResultSetAdapter implements java.sql.ResultSet 

{

public ResultSetAdapter() {}
public boolean next() throws SQLException {throw new SQLException("ResultSet.next() unsupported");}

public int findColumn(String columnName)throws SQLException 

{throw new SQLException("ResultSet.findColumn(String columnName) unsupported");}

public void updateObject(String colIndex, Object obj) throws SQLException {throw new SQLException("ResultSet.updateObject(String colIndex, Object obj) unsupported");}

public void updateObject(String colIndex, Object obj, int s) throws SQLException {throw new SQLException("ResultSet.updateObject(String colIndex, Object obj, int s) unsupported");}
public Statement getStatement() throws SQLException {throw new SQLException("ResultSet.getStatement() unsupported");}
public void close() throws SQLException {throw new SQLException("ResultSet.close() unsupported");}
public void checkClosed() throws SQLException {throw new SQLException("ResultSet.checkClosed() unsupported");} 

}

// ResultSetAdapter를 상속받은 JDBCResultSet

public class JDBCResultSet extends ResultSetAdapter
{
 private     final Cursor cursor;

 private static final NumberFormat  format =
        NumberFormat.getInstance();

 /** Wrap a result set around a Cursor. The cursor
  *  should never have been advanced; just pass this constructor
  *  the return value from {@link Table#rows}.
  */

 public JDBCResultSet(Cursor cursor) throws SQLException
 {

        this.cursor = cursor;
 }

 public boolean next()
 { return cursor.advance();
 }

 public String getString(String columnName) throws SQLException
 { try
  { Object contents = cursor.column(columnName);
   return (contents==null) ? null : contents.toString();
  }
  catch( IndexOutOfBoundsException e )
  { throw new SQLException("column "+columnName+" doesn't exist" );
  }
 }

 public double getDouble(String columnName) throws SQLException
 { try
  { String contents = getString(columnName);
   return (contents == null)
     ? 0.0
     : format.parse( contents ).doubleValue()
     ;
  }
  catch( ParseException e )
  { throw new SQLException("field doesn't contain a number");
  }
 }

 public int getInt(String columnName) throws SQLException
 { try
  { String contents = getString(columnName);
   return (contents == null)
     ? 0
     : format.parse( contents ).intValue()
     ;
  }
  catch( ParseException e )
  { throw new SQLException("field doesn't contain a number");
  }
 }

 public long getLong(String columnName) throws SQLException
 { try
  { String contents = getString(columnName);
   return (contents == null)
     ? 0L
     : format.parse( contents ).longValue()
     ;
  }
  catch( ParseException e )
  { throw new SQLException("field doesn't contain a number");
  }
 }

 public void updateNull(String columnName )
 { cursor.update(columnName, null );
 }
 public void updateDouble(String columnName, double value)
 { cursor.update(columnName, format.format(value) );
 }
 public void updateInt(String columnName, long value)
 { cursor.update(columnName, format.format(value) );
 }
 public ResultSetMetaData getMetaData() throws SQLException
 { return new JDBCResultSetMetaData(cursor);
 }
}

- Coursor 와 java.sql.ResultSet는 적어도 핵심관점에서는 차이가 없다, 또한 JDBCResultSet class는 Cursor 객채를 래핑하고 있기 때문에 Coursor 객체가 인터페이스를 구현하고 있는 것처럼 보일 수도 있다. 하지만 JDBCResultSet은 Cursor(Adaptee)가 Taget 인터페이스(java.sql.ResultSet)를 구현하고 있는 것처럼 보이도록 하는 Adapter이다.

 public final class ArrayIterator implements Iterator
 {
   private int position = 0;
   private final Object[] items;
  
   public ArrayIterator(Object[] items){ this.items = items; }
 
   public boolean hasNext()
   {
     return ( position < items.length );
   }
 
   public Object next()
   {
     if( position >= items.length )
        throw new NoSuchElementException();
      return items[ position++ ];
   }
 
   public void remove()
   {
      throw new UnsupportedOperationException(
      "ArrayIterator.remove()");
   }
 
   /** Not part of the Iterator interface, returns the data
   * set in array form. Modifying the returned array will
   * not affect the iteration at all.
   */
   public Object[] toArray()
   {
      return (Object[]) items.clone();
   }
 }

  Arrayiterator 클래스(Adapter)는 배열(Adaptee)이  Iterator 인터페이스를 구현하고 있는 것 처럼 만들어 주기 때문에 배열을 Iterator를 통해 접근할 수 있게 해준다.

Bridge 패턴 VS Adapter 패턴

  Bridge : 서브시스템들을 분리시키는 거 , 대규모

 Adapter: 어떤 클래스를 이 클래스가 구현하고 있지 않은 인터페이스를 사용하여 작성한 프로그램에 적용시키기 위한 것, 소규모

 Decorator 패턴 VS Adapter 패턴

  Decorator :  어떤 클래스의 메소드를 행위를 상속(Extends)을 하지 않고 변경시키는 것

                    구조 측면에서 보자면 항상 자신이 데코레이팅하는 객체와 같은 인터페이스를 구현한다.

  Adapter :    대부분의 경우 래핑되는 객체의 인터페이스를 구현하지 않는다.

- Command pattern과 비슷하다는 생각이 들어서 찾아본 검색 결과 후 답변

The Command design pattern is used to solve problems like:
- How can an object be configured (customized) with a request?
- And how can the request be (ex)changed dynamically at run-time?

The point of Command is to decouple a request from its invoker and encapsulate it in a separate object (Command interface).
Invoker then delegates a request to a command object dynamically.

The Adapter design pattern (object adapter) is used to solve problems like:
- How can an object be accessed that has an incompatible interface
without changing existing interfaces?

The point of Adapter is to work through a separate object that adapts an incompatible interface, i.e., that implements our needed interface (Target) in terms of (by delegating to) the incompatible interface.

The Command pattern is more similar to the Strategy pattern, which decouples an algorithm from its context and encapsulates it in a separate object (Strategy).

기본 아이디어

State 패턴은 객체의 내부 상태에 따라 행위를 변경할 수 있도록 해준다. 이렇게 하면 객체는 마치 클래스를 바꾸는 것처럼 보인다.

상태에 따라 변화하는 행위를 구현하는 가장 단순한 방법은 현재 상태를 나타내는 필드를 두고, 각 메소드에서 필드 값을 처리하는 switch 문을 두어 case 문이 현재 상태화 관련된 행위를 제공하는 것이다.

 class ChangesBehaviorWithState
{
    private static int state = 0;

    public void methodOne()
    {

    switch( state )
    {
        case 0: /* behavior for state 0 goes here */ break;
        case 1: /* behavior for state 1 goes here */ break;
        case 2: /* behavior for state 2 goes here */ break;
    }
}

public void methodTwo()
{

switch( state )
{
    case 0: /* behavior for state 0 goes here */ break;
    case 1: /* behavior for state 1 goes here */ break;
    case 2: /* behavior for state 2 goes here */ break;
}

}
//...

}

위 접근 방법은 2가지 문제점이 있다.

1. Swich 문은 코드를 읽기 어렵게 만든다

2. 특정 상태와 연관되어 있는 해위를 제공하는 부분이 코드 전반에 흩어져 있기 때문에 유지보수가 어렵게 된다.

그러므로 내부의 상태머신(어떻게 한 상태에서 다른 상태로 바뀌는지, 그리고 각상태와 연관된 행위를 결정하는 룰)을 바꾸는 것이 굉장히 어렵게 된다. 

=> State 패턴으로 이 문제를 해결하자.

 //State Pattern을 사용한 JDBCconnection 객체

public class JDBCConnection extends ConnectionAdapter
{

 private Database database;

 public JDBCConnection(String uri) throws SQLException,
            URISyntaxException,
            IOException
 {

 this( new URI(uri) );
 }

 public JDBCConnection(URI uri) throws SQLException,
           IOException
 { 

database = new Database( uri );
 }

//AutoCommitState을 Enabled State 객체로 설정

private AutoCommitBehavior autoCommitState = enabled;

 public Statement createStatement() throws SQLException
 { 

return new JDBCStatement(database);
 }

 /** Return true if auto-commit mode is enabled */
 public boolean getAutoCommit() throws SQLException
 { 

return autoCommitState == enabled;

}

}

기본 아이디어

어떤 객체(Real Object)를 Real Subject와 동일한 인터페이스를 구현한 다른 중개 객체(Proxy)를 통해 접근하는 것이 땔는 편리할 수 있다는 것이다. 중개 객체는 게으를 초기화(값비싼 필드 등을 필요시 로딩)와 같은 일을 하게 된다.

/** A Map proxy that handles lazy instantiation of tables from the disk.**/

 private final class TableMap implements Map
 {
    private final Map realMap;
    public TableMap( Map realMap )
      {
        this.realMap = realMap;
      }

 }

TableMap이 자신이 포함하고 있는 realMap 객체의 프록시가 된다.

기본 정의

 일련의 객체 집합이 잘 정의된 통로(Chain)를 통해 메시지를 전달함으로써 하나 이상의 객체에 메시지를 처리할 수 있는 기회를 준다. 주어진 메시지에 가장 적합한 객체가 메시지를 처리한다. 또한 하나 이상의 객체가 메시지를 처리하는 것도 가능하다.

• Handler : 이벤트 처리 인터페이스와 다음 이벤트 처리 객체로의 링크를 정의한다.
• Concrete Handler : 요청을 처리, 혹은 아무 일도 하지 않고 이벤트를 다음 객체로 포워딩한다.
• Dispacher : 이벤트를 각 핸들러에 차례로 전달한다. Handler가 링크드 리스트로 구성되어 있으면 필요하지 않다.