Màn hình máy tính 3D đầu tiên có mặt trên thị trường


Hãng Alienware vừa xuất xưởng màn hình OptX AW2310 tích hợp công nghệ tiên tiến nhất của năm 2010.

Alienware OptX AW2310 rộng 23 inch, hỗ trợ độ phân giải Full HD (1920 x 1080), độ quét hình 120 Hz giúp giảm thiểu hiện tượng nhòe hình ngay cả khi hiển thị các cảnh chuyển động cao. Thời gian đáp ứng của sản phẩm đạt 3 ms, độ tương phản động 80.000:1. Alienware cho biết giá của OptX AW2310 khoảng 469 USD, tuy nhiên để được trải nghiệm cảm giác 3D thực sự người dùng phải mua thêm bộ công cụ hỗ trợ 3D của Nvidia (gồm kính, phần mềm và một số phụ kiện khác) với giá 200 USD.

Advertisements

Ước gì – Vân Quỳnh


Nhà ở xã hội “vướng” đất sạch và lợi nhuận


Quy định về lợi nhuận cho doanh nghiệp triển khai nhà ở xã hội còn hạn chế, quỹ đất “sạch” nhiều nơi thiếu trầm trọng – đó là những vấn đề nổi cộm sau một năm triển khai dự án nhà ở xã hội cho người có thu nhập thấp.

88/95 dự án nhà ở sinh viên đã được triển khai trong năm 2009.

Tháng 4/2009, Thủ tướng Chính phủ đã ban hành các Nghị quyết 65, 66, 67 về nhà ở xã hội, mở ra nhiều cơ hội có nhà ở cho các đối tượng là học sinh – sinh viên, công nhân các khu công nghiệp và người có thu nhập thấp tại đô thị.

Cũng từ đó, cụm từ nhà ở xã hội trở nên quen thuộc hơn đối với dư luận khi hàng loạt các dự án nhà ở xã hội được khởi công xây dựng và hy vọng sẽ tạo được nguồn cung dồi dào về nhà ở cho nhu cầu đang bức thiết hiện nay.

Theo báo cáo của Bộ Xây dựng, trong năm 2009 đã có hàng trăm dự án nhà ở xã hội được khởi công. Riêng đối với nhà ở dành cho sinh viên, đã có 88/95 dự án được khởi công với tổng số vốn trái phiếu chính phủ dành cho trong năm 2009 đã đạt tới 3.500 tỷ đồng. Tuy nhiên, sau 1 năm triển khai các chính sách về nhà ở xã hội, nhiều vấn đề vướng mắc đã nảy sinh.

Tại hội thảo “Nhìn lại 1 năm thực hiện các chính sách về nhà ở xã hội và nhà ở cho người có thu nhập thấp” do Hiệp hội BĐS Việt Nam phối hợp cùng Bộ Xây dựng tổ chức, Thứ trưởng Nguyễn Trần Nam cho rằng, quỹ đất “sạch” dành cho nhà ở xã hội trên nhiều địa phương, đặc biệt là Hà Nội và TPHCM đang hết sức thiếu.

Mặc dù địa phương nào cũng cam kết sẽ dành cho nhà ở những ưu tiên về đất đai, nhưng với tình trạng thị trường BĐS và tài nguyên đất đang nóng bỏng như hiện nay, không ít dự án nhà ở xã hội cũng đang gặp cảnh thiếu quỹ đất trầm trọng.

Bên cạnh vấn đề về đất đai, thì việc bố trí nguồn vốn cho các dự án nhà ở xã hội cũng đang gặp khó. Ngoại trừ các dự án nhà ở xã hội dành cho sinh viên, ăn theo nguồn vốn trái phiếu chính phủ, thì các dự án khác đều trông chờ vào vốn xã hội hóa, tức là nguồn vốn từ doanh nghiệp.

Nhưng không phải doanh nghiệp nào cũng mặn mà với các dự án nhà ở xã hội, khi đối tượng thụ hưởng đều là người có thu nhập thấp, khả năng thu hồi vốn chậm.

Quy định về lợi nhuận chưa khuyến khích doanh nghiệp tính toán để hạ thấp giá thành.

Đấy là chưa kể đến việc quy định “đổ đồng” doanh nghiệp chỉ được hưởng lợi nhuận 10% trong dự án nhà ở xã hội có nhiều hạn chế. Thứ trưởng khẳng định, quy định này không khuyến khích các doanh nghiệp tính toán để làm sao hạ thấp giá thành sản phẩm vì dù là giá nhà 6 triệu đồng hay 8 triệu đồng/m2 thì lợi nhuận cũng như nhau…

Chưa hết, nhà ở xã hội cũng gặp phải hội chứng cải cách hành chính. Đối với các Nghị quyết 66, 67, tức là nhà ở xã hội dành cho 2 đối tượng: công nhân tại các KCN và người có thu nhập thấp tại đô thị, Bộ Xây dựng đã có tới 6 thông tư hướng dẫn thi hành.

Trong đó có những thông tư, như ông Nam chia sẻ, hết sức thông thoáng, tạo điều kiện cho doanh nghiệp tham gia vào thị trường nhà ở xã hội. Thế nhưng cho đến hiện tại, việc xây dựng, triển khai cũng như bán nhà ở xã hội vẫn đang khó khăn nhiều do sự chưa rõ ràng của chính sách.

Nhiều địa phương còn chưa có sự chuyển biến tích cực, thậm chí là gây khó khăn cho nhà đầu tư dự án nhà ở xã hội trên địa bàn…

Sau 1 năm thực hiện các chính sách về nhà ở xã hội, có thể thấy rằng đây là những chính sách mang nhiều chất nhân văn, hướng tới những đối tượng nghèo và đang gặp khó khăn nhất của xã hội về nhà ở.

Tuy khoảng thời gian 1 năm không thể đủ dài để đưa một chính sách trở nên hoàn hảo. Sẽ còn nhiều vấn đề cần phải điều chỉnh để các chính sách này thực sự đi vào cuộc sống, phục vụ được đúng đối tượng.

Thế nhưng, 1 năm với hàng trăm dự án nhà ở xã hội được triển khai, có thể thấy đây sẽ là thị trường nhiều tiềm năng, tạo thêm nguồn cung về nhà ở, nhu cầu đang rất thiếu của người dân, cho xã hội.

Giá xăng bất ngờ tăng 450 đồng/lít


Kể từ 18h hôm nay 14/1, Petrolimex chính thức điều chỉnh giá bán lẻ các mặt hàng xăng dầu. Cụ thể, giá xăng tăng thêm 450 đồng/lít, các loại dầu diezel, dầu hỏa và ma zút đồng loạt tăng 300 đồng/lít (kg).
>>  Giá xăng rục rịch tăng 300 đồng/lít
>>  Dầu ma zút tăng 400 đồng/kg

Xăng A92 sẽ lên mức 16.400 đồng/lít.

Theo xác nhận Petrolimex, doanh nghiệp này chính thức điều chỉnh giá xăng dầu bán lẻ trong nước như sau: giá xăng tăng 450 đồng/lít, xăng A92 từ 15.950 đồng/lít lên 16.400 đồng/lít; diezel tăng 300 đồng/lít, diezel 0,05S từ 14.600 đồng/lít lên 14.900 đồng/lít; dầu hỏa tăng 300 đồng/lít, từ 15.200 đồng/lít lên 15.500 đồng/lít.

Riêng dầu ma zút, Petrolimex có 2 mức tăng giá, với loại 3,5S tăng 300 đồng, từ 13.000 đồng/kg lên 13.300 đồng/kg còn ma zút 3S tăng 400 đồng, từ 13.200 đồng lên 13.600 đồng/lít.

Các mặt hàng cùng chủng loại có mức tăng giá tương ứng.

Công ty Xăng dầu Quân Đội cũng điều chỉnh giá bán các mặt hàng xăng dầu từ 18h, với mức xăng tăng 450 đồng/lít; dầu diezel và dầu hỏa tăng 300 đồng/lít.

Còn theo xác nhận từ đại diện Saigon Petro, doanh nghiệp này cũng điều chỉnh tăng giá xăng dầu tương tự: xăng tăng 450 đồng/lít, dầu diezel, dầu hỏa và ma zút đồng loạt tăng 300 đồng/lít (kg) nhưng chậm hơn 1 tiếng so với Petrolimex và Xăng dầu Quân Đội, từ 19h hôm nay.

Các doanh nghiệp kinh doanh xăng dầu đầu mối điều chỉnh tăng giá bán lẻ trong bối cảnh 30 ngày qua, mức giá xăng thành phẩm giao dịch tại thị trường Singapore (đầu mối nhập khẩu của doanh nghiệp Việt Nam) dao động quanh ngưỡng 80 – 82 USD/thùng.

Còn trong một vài ngày gần đây, giá xăng dầu trên thế giới đột ngột tăng cao, giá xăng thành phẩm có lúc lên tới 86 USD/thùng và dầu thành phẩm lên tới gần 88 USD/thùng.

Theo tính toán của đại diện Petrolimex, nếu tính với giá bán của những ngày gần đây 86 – 88 USD/thùng, doanh nghiệp đang chịu lỗ khoảng 900 đồng/lít xăng và gần 1.000 đồng/lít dầu.

Hiện tại, giá xăng dầu tại thị trường Singapore trên trang web của Petrolimex có giá: xăng A92 là 86,21 USD/thùng, diezel 0,25S 88,87 USD/thùng, diezel 0,05S 89,32 USD/thùng, dầu hỏa 90,7 USD/thùng và ma zút 515,7 USD/tấn.

Trước đó, vào ngày 4/1, Petrolimex điều chỉnh giá bán buôn mặt hàng dầu ma zút tăng 400 đồng/kg. Với mức điều chỉnh lần đó, giá bán buôn vùng 1 của mặt hàng ma zút 3S là 13.200 đồng/kg và ma zút 3,5S là 13.000 đồng/kg.

Biểu đồ Use Case


1. Định nghĩa
Là biểu đồ thể hiện sự tương tác, mối quan hệ giữa các Use case và actor trong hệ thống.
2. Mô tả
Mỗi hệ thống thường có một biểu đồ Use case chính thể hiện phạm vi của hệ thống và các chức năng chính của hệ thống. Số lượng các Use case khác được tạo ra sẽ tùy thuộc vào yêu cầu. Có thể là:
    * Một biểu đồ thể hiện tất cả các Use case liên quan đến một actor nào đó
    * Một biểu đồ thể hiện tất cả các Use case được cài đặt trong một giai đoạn phát triển.
    * Một biểu đồ thể hiện một Use case và tất cả các mối quan hệ của nó.
Tuy nhiên nên cân nhắc để các biểu đồ thể hiện đủ các thông tin cần thiết, nếu quá nhiều biểu đồ sẽ gây ra sự nhầm lẫn và mất đi lợi ích của việc đơn giản hóa. Tập hợp các Use case giúp cho khách hàng dễ dàng xem xét ở mức tổng quát hệ thống mà ta sẽ xây dựng. Một hệ thống thông thường có từ 20 đến 50 Use case.
3. Kí hiệu
Một biểu đồ Use case bao gồm một tập các Use case và actor. Giữa Use case và actor có một đường nối nếu như actor đó khởi đầu một Use case.
Biểu Use case có thể lồng nhau, có nghĩa là một Use case trong một biểu đồ Use case có thể được phân nhỏ ra thành những Use case khác, nằm trong một biểu đồ Use case khác.
Ví dụ:
Hệ thống quản lý dự án và nguồn nhân lực. Có bốn Actor là Resource Manager (Người quản lý nguồn nhân lực), Project Manager (Người quản lý dự án), System Administrator (Người quản trị hệ thống) và Backup System(hệ thống sao lưu dữ liệu).
Hình 1-1 là biểu đồ use case ở mức tổng quát, cung cấp một bức tranh toàn cảnh về các actor và use case của hệ thống. Hình 1-2 chi tiết hóa use case "Quản lý nguồn nhân lực" bằng cách chỉ ra các use case mà actor Resource Manager mong muốn ở hệ thống. Resource Manager có thể thêm mới, sửa, xóa các thông tin về kĩ năng của nhân viên. Một kĩ năng phải được tìm ra trong cơ sở dữ liệu trước khi nó được xóa hoặc sửa nên use case FindSkill được tạo ra. Hai use case UpdateSkill và RemoveSkill đều sử dụng chức năng của use case FindSkill nên chúng có quan hệ uses với use case này.
Resource Manager cũng có thể thêm, xóa, sửa các thông tin về nhân viên. Khi cập nhật thông tin về một nhân viên, Resource Manager có thể lựa chọn: thêm kĩ năng cho một nhân viên hay xóa bỏ một kĩ năng của một nhân viên. Do đó hai use case UnassignSkill from Resource và use case AssignSkill to Resource có quan hệ extends với use case UpdateResource để chỉ ra chúng là hai khả năng lựa chọn của use case này.

Hình 1-1: biểu đồ Use case ở mức tổng quát.
Ta có thể xây dựng thêm các biểu đồ chi tiết hơn.

Hình vẽ 1-2: biểu đồ Use case Manage Resource ở mức chi tiết hơn.
Nhìn vào biểu đồ trên ta thấy rõ tác dụng của nó trong việc trao đổi thông tin với khách hàng. Khách hàng có thể biết rõ những chức năng nào sẽ được hệ thống cung cấp. Nhìn vào các actor họ có thể biết chính xác ai sẽ tương tác với hệ thống. Việc này sẽ giúp họ tìm ra các chức năng còn thiếu. Ví dụ như: Khách hàng có thể nói rằng: “ ồ không, các chức năng trên rất hay nhưng  tôi còn muốn xem 10 nhân viên làm việc lâu năm nhất trong công ty”. Và như vậy các chức năng của hệ thống sẽ dễ dàng nắm bắt và đạt được sự nhất trí với khách hàng mà không phải bắt khách hàng đọc quá nhiều tài liệu kỹ thuật như trước.

Posted in UML

Các mối quan hệ trong use case


1. Quan hệ giữa Use case và Actor:
Thường gọi là quan hệ tương tác vì nó thể hiện sự tương tác giữa một actor và một Use case. Mối quan hệ này có thể là hai chiều (từ Actor đến Use case và ngược lại), nó cũng có thể chỉ là một chiều, lúc đó chiều của quan hệ sẽ chỉ ra rằng ai là người khởi tạo liên lạc (communicate). Quan hệ này thể hiện bởi một đường thẳng nối giữa actor và Use case (quan hệ hai chiều) hay một mũi tên (quan hệ một chiều).
2. Quan hệ giữa Use case với Use case:
Có ba loại quan hệ sau: uses, extends và generalization.
Quan hệ Uses (sử dụng):
Có thể có nhiều Use case có chung một số chức năng nhỏ. Khi đó nên tách chức năng đó thành một Use case riêng hơn là mô tả nó trong tất cả các Use case mà cần chức năng đó. Khi đó có một quan hệ Uses giữa các Use case trên và Use case vừa tạo ra.
Ví dụ: trong hệ thống quản lý thư viện, mọi Use case đều bắt đầu bằng việc kiểm tra định danh của người dùng. Chức năng này có thể mô tả trong một Use case tên là “Đăng nhập hệ thống”, sau đó các Use case khác sẽ sử dụng Use case này khi cần thiết.
Quan hệ Extends (mở rộng):
Không giống như quan hệ Uses trong đó nói rằng khi một Use case A sử dụng Use case B có nghĩa là trong khi thực hiện Use case A phải thực hiện Use case B, quan hệ Extends dùng để chỉ:
    * Các hành vi tùy chọn: có thể thực hiện hoặc không.
      Ví dụ: khi gửi email có thể thực hiện các thao tác bảo mật nội dung thư hoặc là không. Ta có Use case “Bảo mật” có quan hệ extends với Use case “Gửi email”.
    * Các hành vi mà chỉ thực hiện trong một số điều kiện nhất định.
      Ví dụ như: Khi thêm sách mới trong thư viện thì phải nhập các từ khóa cho nó, nếu từ khóa chưa có phải thực hiện thêm từ khóa rồi mới tiếp tục thực hiện thêm các thông tin về sách. Ta có Use case “Thêm từ khóa” có quan hệ extends Use case “Thêm sách”.
    * Một số hành vi khác sẽ được thực hiện phụ thuộc vào sự lựa chọn của người dùng.
      Ví dụ như: người dùng của hệ thống rút tiền tự động có thể chọn Rút tiền nhanh hoặc Rút tiền theo cách bình thường. Ta có Use case “Rút tiền nhanh” có quan hệ extends với Use case “Rút tiền”.
Quan hệ Generalization (thừa kế):
Cũng giống như quan hệ thừa kế giữa hai lớp, quan hệ thừa kế giữa use case A và use case B nói lên rằng use case B kế thừa những đặc điểm của use case A ngoài ra nó cũng có thể có thêm những đặc trưng riêng của nó.
Ví dụ: như kiểm tra định danh người dùng có thể theo nhiều cách: Kiểm tra mã số, kiểm tra dấu vân tay…
Khi đó cả hai đều thực hiện một số hành động tương đối giống nhau của một lớp hành động gọi là “Kiểm tra định danh người dùng”.

Posted in UML

Use Case


1. Định nghĩa
Là một khối chức năng được thực hiện bởi hệ thống để mang lại một kết quả có giá trị đối với một actor nào đó.
2. Mô tả
Use case mô tả sự tương tác đặc trưng giữa người dùng và hệ thống. Nó thể hiện ứng xử của hệ thống đối với bên ngoài, trong một hoàn cảnh nhất định, xét từ quan điểm của người sử dụng. Nó mô tả các yêu cầu đối với hệ thống, có nghĩa là những gì hệ thống phải làm chứ không phải mô tả hệ thống làm như thế nào. Tập hợp tất cả Use case của hệ thống sẽ mô tả tất cả các trường hợp mà hệ thống có thể được sử dụng.
Một Use case có thể có những biến thể. Mỗi một biến thể được gọi là một kịch bản (scenario). Phạm vi của một Use case thường được giới hạn bởi các hoạt động mà người dùng thực hiện trên hệ thống trong một chu kì hoạt động để thực hiện một sự kiện nghiệp vụ.
Một Use case mô tả một nghiệp vụ thông thường. Nghiệp vụ này bao gồm các bước riêng rẽ, còn được gọi là các hoạt động. Khi các bước được mô tả dưới dạng văn bản thì việc chỉ ra sự phụ thuộc giữa các bước là một việc mất nhiều thời gian. Việc thể hiện các bước dưới dạng kí hiệu là dễ dàng và dễ hiểu hơn. Do đó Use case thường được mô tả chi tiết thông qua các biểu đồ mô tả hành vi (behavior) như biểu đồ hoạt động (activity diagram), biểu đồ trình tự (sequence diagram), biểu đồ hợp tác(collaboration diagram).
Use case cũng có thể được mô tả thông qua các thiết kế nguyên mẫu màn hình, các ví dụ về biểu mẫu báo cáo. Điều này giúp cho người dùng dễ dàng mường tượng hệ thống sẽ làm việc như thế nào, qua đó có thể kiểm tra tính đúng đắn của Use case.
Các câu hỏi thường được sử dụng để xác định Use Case cho một hệ thống là:
    * Nhiệm vụ của mỗi actor là gì?
    * Có actor nào sẽ tạo, lưu trữ, thay đổi, xóa hoặc đọc thông tin trong hệ thống?
    * Có actor nào cần báo tin cho hệ thống về một thay đổi đột ngột từ bên ngoài?
    * Có actor nào cần được thông báo về một sự việc cụ thể xảy ra trong hệ thống?
    * Trường hợp sử dụng nào sẽ hỗ trợ và bảo trì hệ thống?
    * Tất cả các yêu cầu về mặt chức năng có được thể hiện hết thông qua các trường hợp sử dụng chưa?
Điều gì tạo nên một Use Case tốt
Có một câu hỏi thường xuyên được đặt ra về mức độ chi tiết của Use case. Nó nên ở mức độ nào là tốt. Có lẽ không có câu trả lời hoàn toàn đúng, nhưng có một số nhận xét như sau: "Một Use case thường biểu hiện một chức năng được thực hiện trọn vẹn (không ngắt quãng) từ đầu đến cuối. Một Use case phải mang lại một điều gì đó có giá trị đối với actor".
Mô tả Use case
Use case cần có một vài câu ngắn gọn mô tả mục đích của Use case, cho ta biết chức năng do Use case cung cấp.
3. Kí hiệu
Một Use case được thể hiện bởi một hình ellip kèm theo tên của Use case. Ngoài ra còn có thể có thêm các chú thích để mô tả chi tiết hơn về ý nghĩa của Use case. Mỗi Use case trong hệ thống có tên phân biệt duy nhất. Use case có thể được đánh số để thuận tiện cho việc tra cứu nhanh trên biểu đồ hoặc trong tài liệu mô tả.
Ví dụ:

4. Luồng sự kiện cho một Use case (The Flow of events)
Use case chỉ cung cấp một khung nhìn ở mức cao, tổng quát. Để hiểu rõ hơn hệ thống cần phải làm gì thì cần phải mô tả chi tiết hơn, gọi là luồng sự kiện. Nó là một tài liệu mô tả các hoạt động cần thiết để đạt được ứng xử mong đợi của Use case.
Tuy là mô tả chi tiết nhưng luồng sự kiện vẫn được viết sao cho có thể chỉ ra những gì hệ thống cần làm chứ không phải chỉ ra hệ thống làm như thế nào.
Ví dụ: trong luồng sự kiện chúng ta nói “Kiểm tra mã của người dùng” chứ không nói rằng việc đó phải thực hiện bằng cách xem xét ở trong một bảng nào đó trong cơ sở dữ liệu. Nó mô tả chi tiết những gì người dùng của hệ thống sẽ làm và những gì hệ thống sẽ làm. Nó cần phải đề cập tới:
    * Use case bắt đầu và kết thúc khi nào và như thế nào
    * Có những sự tương tác nào giữa Use case và actor để thực hiện chức năng đó.
    * Những dữ liệu nào cần thiết cho Use case
    * Thứ tự thực hiện thông thường của các sự kiện
    * Các mô tả về các luồng ngoại lệ hoặc rẽ nhánh.
Mỗi dự án cần có một mẫu chuẩn cho việc tạo tài liệu về luồng sự kiện. Có thể dùng theo mẫu đơn giản như sau:
    * X. Luồng sự kiện cho Use case ABC
    * X1. Điều kiện bắt đầu: danh sách những điều kiện phải thỏa mãn trước khi Use case được thực hiện. Ví dụ như: một Use case khác phải thực hiện trước khi Use case này được thực hiện hay người dùng phải có đủ quyền để thực hiện Use case này. Không nhất thiết mọi Use case đều phải có điều kiện bắt đầu.
    * X2. Luồng chính: mô tả những bước chính sẽ xẩy ra khi thực hiện Use case.
    * X3. Các luồng phụ( luồng con).
    * X4. Các luồng rẽ nhánh.
Trong đó X là số thự tự của Use case trong hệ thống.
Ví dụ: Luồng sự kiện mô tả Use case cho hệ thống rút tiền tự động như sau:
    1.1 Điều kiện bắt đầu.
    1.2 Luồng chính:
        1.2.1 Người dùng đưa thẻ vào máy.
        1.2.2. Máy hiển thông báo chào mừng và yêu cầu nhập mã số
        1.2.3 Người dùng nhập mã số
        1.2.4 Máy xác nhận mã số đúng. Nếu nhập sai mã số, luồng rẽ nhánh E-1 được thực hiện.
        1.2.5 Máy hiện ra ba lựa chọn:
            * Rút tiền: luồng con A-1
            * Chuyển tiền: luồng con A-2
            * Thêm tiền vào tài khoản: luồng con A-3
        1.2.6 Người dùng chọn rút tiền
    1.3. Luồng con:
        1.3.1 Luồng con A-1:
        1.3.1.1 Máy hỏi số lượng tiền cần rút
        1.3.1.2 Người dùng nhập số tiền cần rút
        Máy kiểm tra trong tài khoản có đủ tiền không. Nếu không đủ luồng rẽ nhánh E-2 được thực hiện
        ….
    1.4. Luồng rẽ nhánh:
        1.4.1 E-1: Người dùng nhập sai mã số
            Máy thông báo là người dùng đã nhập sai mã số yêu cầu người dùng nhập lại hoặc hủy bỏ giao dịch.
        1.4.2 E-2: Không đủ tiền trong tài khoản…

Posted in UML