Tài liệu Phân tích hệ thống hướng đối tượng pdf

Chương 2- Bài giảng Phân tích hướng đối tượng Chương 3: Xây d ng mô hình các nhu c u ự ầ I. Chuẩn bị bắt đầu phân tích II. Xác định phạm vi dự án III Lập sơ đồ ngữ cảnh (context diagram) IV. Lập sơ đồ hoạt vụ (use case diagram) V. Mô tả các giao diện - giao diện người- máy - giao diện với hệ thống khác I. CHUẨN BỊ BẮT ĐẦU PHÂN TÍCH: I.0 Giới thiệu: Tình huống cổ điển là chúng ta- những chuyên viên giỏi về CNTT- đối mặt với một nhóm người dùng, trong đó có một số người sợ máy tính hoặc sợ công nghệ nói chung, và mỗi nhóm thấy nhóm kia sử dụng một ngôn ngữ quả là xa lạ với mình. Chúng ta phải làm công việc cũng khá hay là học để hiểu thế giới của họ, công việc của họ, công nghệ của họ, tiếng lóng của họ, và những điều này chả ăn nhập bao nhiêu với mình. Lưu ý rằng thực ra, chúng ta cũng chẳng khác gì trẻ sơ sinh, thử tìm hiểu một thế giới hoàn toàn xa lạ mà ta vừa bị ném phịch vào đó. Công việc chúng ta hết sức phức tạp bởi sự giao tiếp khó khăn, nỗi e sợ của người dùng, và thường là chính sự bỏ sót của chúng ta về những điều người dùng thực sự làm. Chúng ta đã rất hay nghĩ rằng họ đã hiểu vấn đề, sẽ phải vội vã … Thông thường, giải pháp chúng ta đưa ra theo cách này hóa ra hoàn toàn vô ích bởi vì nó giải quyết chưa đúng vấn đề. Nó chạy cũng tốt đó, nhưng chẳng làm được gì có giá trị cho người dùng cả ! Liệu pháp cho vấn nạn này liên quan đến việc chúng ta đã xử lý, vận dụng mối quan hệ với người dùng của mình như thế nào. Đối với việc phân tích hệ thống, tất nhiên ta phải có hiểu biết kỹ thuật và kiến thức về công việc. Nhưng điều tạo nên những nhà phân tích tài năng khác với những nhà phân tích tốt tầm tầm, chính là mức độ của kỹ năng về con người. Trong chương này, ta sẽ xem xét từng bước các chi tiết của cách thức tiếp cận người dùng và trích ra từ đó những điều ta cần. Nhà phân tích tài năng thiết kế những hệ thống làm cho người dùng không chỉ hài lòng, mà cảm thấy vui thích. Có vẻ như quá dễ khi chỉ đơn giản bảo rằng người dùng có trách nhiệm cho ta những thông tin mà ta cần, để xây dựng cho họ hệ thống tốt nhất có thể được, bởi vì rốt cuộc thì họ sẽ là người thụ hưởng nó. Xét cho cùng, toàn bộ mục đích hệ thống là làm cho người dùng thực hiện công việc của họ tốt hơn với ít căng thẳng và rắc rối hơn, có lợi cho chính họ, lẫn cho khách hàng. Nhưng điều đó lại không đáp ứng đúng vấn đề, thế giới không đơn giản diễn ra như thế. Nói chung, và phải nói ngay với một số ngoại lệ đáng kể, rằng người dùng có rất ý tưởng về điều chúng ta cần biết. Điển hình như, người dùng rất hiểu biết về lĩnh vực của mình, nhưng chưa bao giờ họ kiểm lại chuyên ngành của họ từ quan điểm hơi lạ ta yêu cầu, quan điểm dựa trên thông itn và dữ liệu. Như vậy, khi muốn thành công trong dự án Phạm Thị Xuân Lộc 1 Chương 2- Bài giảng Phân tích hướng đối tượng đó, ta cần tiếp cận các công việc với thái độ là ta sẵn sàng làm bất cứ cái gì cần thiết cho một phân tích hệ thống thành công. Như những “chuyên gia”, ta cần phải khó nhọc để giúp cho người dùng cảm thấy thoải mái, tiện lợi khi tham gia vào việc gì đó mà đối với họ, đôi khi là một qui trình hơi đáng ngại. Chúng ta phải kiên nhẫn đến khi họ tin cậy ta, cảm thấy thoải mái để mở lòng ra, nói lên những điều họ nghĩ và cảm nhận. Xa hơn trong quá trình phân tích, ta có thể kỳ vọng họ cùng tham gia vào dự án một cách tự nguyện và nhiệt tình, nhưng với nhiều mức độ e ngại khác nhau lúc đầu. Sự tham gia tự nguyện này từ người dùng là cách duy nhất để ta có thể đảm bảo một nền tảng vững chắc, đúng đắn cho hệ thống chúng ta đang xây. Ta cần phải có những chuẩn bị thật cần thiết từ ngay trước buổi họp đầu tiên. Có nhiều cách để tiếp cận cho việc phân tích, mỗi cách có thế mạnh riêng. Ta có thể thích nghi và điều chỉnh một phương pháp trong số đó cho thích hợp với tình huống. Với các nhà lãnh đạp cao cấp bận rộn, bạn chỉ có thể gặp họ một hoặc hai lần, hoặc có thể không được lần nào. Trong trường hợp đó, bạn sẽ gặp lần lượt từng người, kết hợp lại các kết quả gặp gỡ đó, luân chuyển thông tin tổng hợp đó, rồi lại gặp gỡ từng người một lần nữa để thảo luận và chỉnh sửa mô hình tổng thể. Bất cứ phương pháp nào bạn chọn cũng nhằm phản ánh cái nhìn và quan điểm của người dùng, và lập sưu liệu về kiến thức của người dùng về công việc của họ, chứ không phải cái chúng ta, những nhà phân tích, có thể nghĩ. Và nó phải bao hàm nhập liệu (input) của tất cả các người dùng, đặc biệt là những người nhút nhát, rụt rè, ẩn dật. Một phương pháp được ưa thích là FTS (facilitated team session) hoặc còn gọi là JAD (joint application development). Các người dùng và các nhà phân tích gặp nhau như một nhóm trong một số buổi có thể cần đến mấy giờ liền. Sau đây là một số hướng dẫn để tiến hành những điều trên. I.1 Người tham dự (attendees): Ta sẽ cần đủ loại người dùng, ở mọi cấp và ở mọi bộ phận của công việc mà ta đang muốn mô hình hóa. I.1.1 Cấp lãnh đạo cao nhất (senior managers): Ta sẽ cần mời họp một số nhà quản lý, ở cấp mà bạn có thể tiếp cận được, để mang lại trọng lượng từ ảnh hưởng và quyền lực của họ, và để có một tầm nhìn to rộng. Sự hiện diện của họ làm tăng lên khá nhiều tin tưởng trong đầu người dùng cấp dưới. Từ đó, họ được động viên để đảm nhận dự án nghiêm túc hơn. Hãy ghi nhớ rằng người dùng thông thường không hiểu nhiều lắm dự án quan trọng thế nào đến công việc của họ để có được thông tin tốt, và hệ thống thông tin tốt. Sự hiện diện của giới lãnh đạo quan trọng nhất ở lúc đầu dự án, làm tăng thêm độ mạnh quyền lực của họ vào những việc như phạm vi dự án. Người dùng hay có khuynh hướng đẩy phạm vi dần lên về sau vượt quá kích cỡ mà bạn đã tiên liệu. Việc này sẽ hơn khó hơn nhiều với họ, khi ta có thể cầu viện đến quyền lực của lãnh đạo để bắt họ chấp nhận ranh giới của dự án. Điều này cũng giải thích tại sao là quan trọng việc đặc tả những điều nằm trong và nằm ngoài dự án. Tất nhiên, khi ta là nhà tư vấn với một hợp đồng có giá đã xác định thì đây là vấn đề sống còn ! I.1.2 Người lao động trực tiếp (workers): Phạm Thị Xuân Lộc 2 Chương 2- Bài giảng Phân tích hướng đối tượng Ở cực khác, ta luôn nên có những người ở “tầng lớp dưới” (shop floor). Những người lao động đang thực sự vận hành doanh nghiệp thường biết các chi tiết hoặc thủ tục tại chỗ rất rõ, nhưng lại chưa được chủ biết đến (hoặc có thể họ đang bị che dấu có chủ yếu từ giới chủ !). Ta phải học những điều thực sự đang diễn ra trong thế giới người dùng, không phải là cái mà các ông chủ, hoặc tài liệu giới thiệu công ty trình bày Có khi một nhân công rất bình thường nhưng hiểu rõ thật chi tiết công việc của mình, có thể giúp ta xây dựng thật thành công mô hình cho hệ thống. Và còn có một khía cạnh khác trong việc tham gia của cấp lao động trực tiếp. Sự tham dự của họ sẽ làm tăng lên ý nghĩa tính sở hữu mà người lao động cảm nhận được về hệ thống. Rất thường xảy ra việc người dùng cấp đó sẽ nhanh chóng cảm thấy những nhà phát triển hệ thống và chính cấp quản lý của họ vừa âm mưu ép buộc họ chấp nhận sử dụng hệ thống mới. Khi thấy ít hoặc không có lợi gì cho họ trong công việc cực nhọc thường ngày, họ mau chóng nhận ra các thủ tục mới cần học và khối lượng công việc tăng lên. Điều này liên quan đến nỗi sợ bị đánh giá thấp nếu họ gặp các rác rối khi phải điều chỉnh theo hệ thống mới, do đó họ sẽ có thể chịu một loạt áp lực căng thẳng. Một sự thiếu hợp tác chỉ là phản ứng đầu tiên. Sự chống đối của họ có thể tiến triển đến một mức độ có thể gọi đó là “phá hoại thụ động (passive sabotage). Đây là một quá trình tinh vi, không dễ phát hiện mà việc kết tội và tìm chứng cứ trở nên không thể và không thích đáng. Nó ở dạng như quên một số việc do “do sự cố”, hoặc “không cố ý” quá hạn (missing deadline), v.v… Tác động tích lũy của hàng tá, hoặc hàng trăm “sự cố” nhỏ như thế là hệ thống của ta thể hiện như thể là không đạt, thậm chí là vô tích sự. Cách chắc chắn nhất để tránh “Chiến tranh lạnh trong một tách trà” (Cold War in a teacup) như vậy là có họ cùng một phía với mình, kể họ ra với nhóm của mình, và đảm bảo họ có cung cấp nhập liệu vào toàn bộ quá trình phát triển hệ thống. Không những họ phải có nhập liệu, mà họ còn phải thấy nhập liệu của họ đang được tìm, được chấp nhận và được sử dụng như thế nào. Mỗi khi người lao động nhận ra họ đang được lắng nghe, họ sẽ có một số kiểm soát cho số phận của họ, và những vấn đề họ bày tỏ được chú ý, họ sẽ đề cập đến hệ thống “của chúng ta” (có vẻ họ đã đổi cách nói, quan điểm), chứ không còn gọi đó là hệ thống của mấy người máy. I.1.3 Lãnh đạo cấp trung (junior managers): Nhóm người cuối cùng nên mời là những người quản lý cấp thấp và cấp giữa. Những đốc công, giám thị, và những nhà quản trị này liên quan đủ chặt với mức độ vận hành thực sự để có một ý tưởng rõ ràng về công việc hàng ngày của nhân viên thuộc quyền của của họ. Họ lại còn có quan điểm rộng hơn, có tính chiến lược hơn nhân viên của họ. Đây là những nhà qui hoạch khôn khéo và tỉ mỉ, nhập liệu của họ có tính chủ yếu cho thành công của dự án. I.2 Nhà phân tích phụ trách ghi nhận và tư liệu (recording analyst): Ta cần một người được chỉ định để ghi lại, lập thành các sưu liệu của các phiên họp, các công đoạn (sessions), chính yếu là ghi nhận tiến triển sau mỗi buổi họp. Điều quan trọng là người này phải hiểu được quá trình. Một người dùng có kinh nghiệm về các dự án hệ thống và các phương pháp mô hình hóa cũng có thể đảm nhận vai trò này. Điều quan trọng không phải gán công việc này cho ai có khả năng tốc ký hoặc viên chức nào cũng được, mà phải là người biết lọc kiến thức trong chức năng này. I.3 Đại đa số người dùng (user majority): Phạm Thị Xuân Lộc 3 Chương 2- Bài giảng Phân tích hướng đối tượng Những người thiết kế và lập trình nên ở trong nhóm thiểu số, không tham gia vào nhóm này, để tránh áp đảo người dùng và làm họ rụt lại. Khi người dùng đông hơn người thiết kế, họ sẽ mạnh dạn đứng lên và bày tỏ quan điểm của mình, nói lên những nguy cơ có thể. Tuy nhiên, tùy vào cỡ nhóm, tốt nhất nên có hai nhà lập mô hình- người lãnh đạo và người ghi nhận sưu liệu. I.4 Giải trí (distraction): Nếu có thể được, nên tổ chức họp ở nơi nào mà bạn có thể kiểm soát được môi trường. Ngược lại, chọn một nơi “trung lập”. Không nên chọn nơi của người dùng, có điện thoại và phiền nhiễu từ các nhân viên. Ta cần có một sự tập trung và hướng về nhiệm vụ cần thực hiện. I.5 Kiến thức nền (background): Cần nghiên cứu nhóm người dùng, cấu trúc và chức năng của họ. Cần biết về mối tương quan về mặt báo cáo của họ, như thế ta sẽ biết trước ai làm việc cho ai. Bạn cần nghiên cứu trước tiếng lóng, thuật ngữ, từ viết tắt, v.v… của họ, và từ đó bạn có thể nhận được các bảng giải thích tóm tắt (glossaries), tài liệu đào tạo, các quyển brochures giới thiệu công ty, các báo cáo hàng năm, và các báo cáo đặc biệt. I.6 Môi trường: Bảng trắng nhựa, hoặc bảng phấn là cái phải có. Một bảng trắng tự photo được là một ý tuyệt vời, vì người ghi nhận sẽ có một bản sao về những gì nhà lãnh đạo đang viết, ngoài bản chính thức đã có cấu trúc, tổ chức hẳn hoi. Một máy chiếu cũng rất hữu ích. Nên đảm bảo nhiệt độ tỏng phòng đủ sức làm mọi người tỉnh táo, nên hơi mát. Thà rằng có người phải mặc áo khoác, còn hơn có người gật gù ngủ gật. Đối với công việc về đầu óc thế này, cần giữ đầu lạnh và người ấm. Cần khuyến khích ăn mặc tự nhiên, đặc biệt khi xa khỏi các đôi mắt đồng nghiệp. Như vậy sẽ giúp các nhà lãnh đạo ít làm nhân viên của mình e dè. Mặt khác, bạn với tư cách một nhà thiết kế, cần giữ một chút phong thái chuyên nghiệp, do đó bạn nên ăn mặc trang trọng hơn một chút so với người dùng và so với thường ngày. Nên sắp xếp chỗ ngồi theo cách không lễ nghi quá. Cà-phê, nước, và nước trái cây trong phòng sẽ rất có ích, bởi vì chúng cho phép người ta đứng dậy và thỉnh thoảng đi vòng quanh một chút chỉ trong phòng. Nên châm thêm, thay nước trong phòng khi giải lao sẽ giảm thiểu khoảng gián đoạn trong giờ giải lao, và khuyến khích người ta vẫn có thể tiếp tục thảo luận chủ đề đang bàn đến. Điều đó cũng giảm bớt số người về lại văn phòng của họ hoặc đi gọi điện thoại. Việc hút thuốc lá cũng là một vấn đề tế nhị. Tốt nhất là không nên cho hút thuốc trong buổi họp. I.7 Lịch biểu (schedule): Người dùng phải ý thức trước rằng cách thức thống nhất về thời gian là do từ phía họ. Lập lịch biểu đầy đủ trước cho các phiên họp (session). Có 2-4 giờ/ phiên là tối ưu, bởi vì bọ não thường trực có nguy cơ làm việc không hiệu quả sau đó. Nên lập lịch họp nửa ngày vào buổi sáng nếu có thể được; tuyệt đối không nên họp ngay sau giờ ăn trưa. Nếu bạn nhận thấy có một vài cặp mắt đang díp lại thì nên cho khoảng 3 phút giải lao để họ có thể tỉnh dậy và dùng một tách cà-phê rồi trở lại ghế. Mặc dù nhận thấy buổi họp nửa ngày là tối ưu, vẫn thường có nhu cầu phải làm mô hình đến nhiều ngày. Khi đó, hãy ghi nhớ những điều dặn dò ở trên và cân nhắc làm điều tốt nhất. I.8 Xác nhận lại: Phạm Thị Xuân Lộc 4 Chương 2- Bài giảng Phân tích hướng đối tượng Nên xác nhận lại buổi họp một ngày trước đó, với đảm bảo là không có đụng độ với công việc gì khác về mặt thời gian. Ta nên hỏi một người rằng ta đã có bảo họ về giờ họp hay chưa, mặc dù ta biết chắc ta đã làm thế rồi. Điều này giúp người đối diện có thể đã quên nhưng không cần phải thú nhận, và như thế giữ được thể diện cho họ, giúp họ không những biểu lộ cố gắng, mà còn nhiệt tình cộng tác với ta. II. XÁC ĐỊNH PHẠM VI DỰ ÁN: III LẬP SƠ ĐỒ NGỮ CẢNH (CONTEXT DIAGRAM) IV. LẬP SƠ ĐỒ HOẠT VỤ (USE CASE DIAGRAM) V. MÔ TẢ CÁC GIAO DIỆN - giao diện người- máy - giao diện với hệ thống khác Phạm Thị Xuân Lộc 5 . Chương 2- Bài giảng Phân tích hướng đối tượng Chương 3: Xây d ng mô hình các nhu c u ự ầ I. Chuẩn bị bắt đầu phân tích II. Xác định phạm vi dự. ! Liệu pháp cho vấn nạn này liên quan đến việc chúng ta đã xử lý, vận dụng mối quan hệ với người dùng của mình như thế nào. Đối với việc phân tích hệ thống,